Tavaliselt eristatakse IP loomise järgmisi etappe:

1. süsteeminõuete kujundamine,

2. disain,

3. rakendamine,

4. testimine,

5. kasutuselevõtt,

6. käitamine ja hooldus.

IS-i loomise protsessi algetapp pärast süsteemi loomise eesmärgi kindlaksmääramist on äriprotsesside modelleerimine - omavahel seotud tööde kogum organisatsioonis esineva konkreetse probleemi lahendamiseks ning selle eesmärkide ja eesmärkide realiseerimiseks. Äriprotsesside ja ärifunktsioonide lõikes kirjeldatud organisatsioonimudel võimaldab sõnastada IS-i põhinõuded.

IS loomise algetappide eesmärk, mis tehakse organisatsiooni tegevuse analüüsimise etapis, on IP nõuete kujundamine, kajastades korrektselt ja täpselt kliendiorganisatsiooni eesmärke ja eesmärke. Organisatsiooni vajadustele vastava infosüsteemi loomise protsessi täpsustamiseks on vaja välja selgitada ja selgelt sõnastada, mis need vajadused on. Selleks on vaja välja selgitada kliendi nõuded IS-ile ja kaardistada need mudelkeeles IS-projekti arendamise nõuetesse, et tagada vastavus organisatsiooni eesmärkidele ja eesmärkidele.

Laval disain Kõigepealt moodustatakse andmemudelid. Disainerid saavad analüüsitulemused esialgse teabena. Loogiliste ja füüsiliste andmemudelite loomine on andmebaasi kujundamise oluline osa. Analüüsiprotsessi käigus saadud infomudel teisendatakse esmalt loogiliseks ja seejärel füüsiliseks andmemudeliks.

Paralleelselt andmebaasi skeemi kujundamisega viiakse läbi protsesside kavandamine, et saada kõikide IS moodulite spetsifikatsioonid (kirjeldused). Mõlemad disainiprotsessid on omavahel tihedalt seotud, kuna osa äriloogikast on tavaliselt andmebaasis juurutatud (piirangud, päästikud, salvestatud protseduurid). Protsesside kavandamise põhieesmärk on kaardistada analüüsifaasis saadud funktsioonid infosüsteemi mooduliteks. Projekteerimisetapi lõpptoodeteks on andmebaasiskeem (põhineb analüüsietapis välja töötatud ER mudelil) ja süsteemimoodulite spetsifikatsioonide komplekt (need on üles ehitatud funktsioonimudelite alusel).

Lisaks toimub projekteerimisetapis ka IS-i arhitektuuri arendus, sealhulgas platvormi (platvormid) ja operatsioonisüsteemi (operatsioonisüsteemid) valik. Heterogeenses IS-is võivad mitmed arvutid töötada erinevatel riistvaraplatvormidel ja erinevatel operatsioonisüsteemidel. Lisaks platvormi valikule määratakse projekteerimisetapis mõned arhitektuuri tunnused (failiserver või klient-server, tsentraliseeritud andmebaas või hajutatud, homogeenne andmebaas või mitte, kas jõudluse parandamiseks kasutatakse paralleelseid andmebaasiservereid). Projekteerimisetapp lõpeb IP tehnilise projekti väljatöötamisega.

Laval rakendamine luuakse süsteemitarkvara, installitakse riistvara ja töötatakse välja töödokumentatsioon.

Lava testimine ilmub tavaliselt aja jooksul jaotatuna.

Pärast üksiku mooduli arendamise lõpetamist teostab süsteem offline testi, millel on kaks peamist eesmärki: mooduli rikete tuvastamine ja mooduli vastavus spetsifikatsioonile (kõikide vajalike funktsioonide olemasolu, mittevajalike funktsioonide puudumine). Pärast autonoomse testi edukat läbimist lülitatakse moodul süsteemi arendatud ossa ja loodud moodulite rühm läbib ühendustestid, mis peaksid jälgima nende vastastikust mõju. Järgmisena testitakse moodulite rühma töökindlust, st need läbivad esiteks süsteemi rikkeid simuleerivad testid ja teiseks riketevahelise keskmise aja testid. Seejärel läbib kogu moodulite komplekt süsteemi testi – toote sisemise vastuvõtutesti, mis näitab selle kvaliteedi taset. See hõlmab funktsionaalsusteste ja süsteemi töökindluse teste. Infosüsteemi viimane test on vastuvõtutest. Selline test hõlmab infosüsteemi kliendile näitamist ja peab sisaldama reaalseid äriprotsesse simuleerivate testide rühma, et näidata juurutuse vastavust kliendi nõuetele.

2. Infosüsteemi arhitektuuri mõiste

Vaatleme erinevatest allikatest antud "infosüsteemi arhitektuuri" määratlust:

Arhitektuur on süsteemi organisatsiooniline struktuur.

ArhitektuurIS– mõiste, mis määratleb infosüsteemi mudeli, struktuuri, täidetavad funktsioonid ja komponentide omavahelised seosed.

Arhitektuur- see on süsteemi põhikorraldus, mis väljendub selle komponentides, nende suhetes üksteise ja keskkonnaga, samuti põhimõtetes, mis määravad süsteemi ülesehituse ja arendamise.

Arhitektuur– see on kogum olulisi otsuseid tarkvarasüsteemi korralduse kohta, struktuurielementide kogum ja nende liidesed, millega süsteem on kokku pandud, koos nende käitumisega, mis on määratud nende elementide vahelises koostoimes, elementide paigutuse järk-järgult suuremateks alamsüsteemideks. ja stiil arhitektuur, mis juhib seda organisatsiooni – elemendid ja nende liidesed, interaktsioonid ja paigutus.

Arhitektuur on organisatsiooni struktuur ja sellega seotud süsteemi käitumine. Arhitektuur saab rekursiivselt lahti võtta osadeks, mis interakteeruvad liideste, osi ühendavate ühenduste ja osade kokkupanemise tingimuste kaudu. Liideste kaudu suhtlevad osad hõlmavad klasse, komponente ja alamsüsteeme.

Kui ühendame kõik need määratlused, saame järgmise:

IP-arhitektuur on IS-i komponentide, nende ja väliskeskkonna vaheliste seoste ning süsteemide arendamise ja toetamise põhimõtete ja vahendite põhikorraldus.

Tarkvarasüsteemide arhitektuuri all peame silmas otsuste kogumit, mis puudutavad:

· tarkvarasüsteemi organiseerimine;

· süsteemi moodustavate konstruktsioonielementide ja nende liideste valik;

· nende elementide käitumine koostoimes teiste elementidega;

· nende elementide ühendamine alamsüsteemideks;

· arhitektuurne stiil, mis määrab süsteemi loogilise ja füüsilise korralduse: staatilised ja dünaamilised elemendid, nende liidesed ja nende kombineerimise meetodid.

Arhitektuur Tarkvarasüsteemi struktuur ei hõlma mitte ainult selle struktuurseid ja käitumuslikke aspekte, vaid ka selle kasutamise ja teiste süsteemidega integreerimise reegleid, funktsionaalsust, jõudlust, paindlikkust, töökindlust, korduvkasutatavust, täielikkust, majanduslikke ja tehnoloogilisi piiranguid ning kasutajaliidese probleeme.

Tarkvarasüsteemide arenedes muutub nende omavaheline integreerimine järjest olulisemaks, et luua ettevõttele ühtne inforuum.

Pole midagi raskemat, ohtlikumat ja ebakindlamat kui uue asjade korra juurutamise juhtimine, sest igal uuendusel on tulihingelised vaenlased, kes elasid hästi vana all, ja loiud toetajad, kes pole kindlad, kas suudavad uue korra järgi elada.
N. Machiavelli

Ja nüüd hakkab projekti huvitav ja täis loovust, projektsiooni, loovust ja loomingut lõppema. Oma otsuse kaitsmise karm argipäev saab alguse konkreetse ettevõtte tegelikust õhkkonnast ja mis kõige tähtsam, kõik on ka kehtiva seadusandluse raames.

Alustuseks tuleb juurutatud toode kasutusele võtta seadmetel, mis on ettevalmistatud selle proovitöö korraldamiseks.

1. Süsteemi kasutuselevõtt pilootoperatsiooni kohas

Vastavalt projekteeritud tehnoloogilisele arhitektuurile, mis kajastub dokumentatsioonis, ostetakse serveri-, side- ja muud seadmed ning süsteemitarkvara. Infosüsteemi komponendid koondatakse ühtseks riist- ja tarkvarakompleksiks kohtades, kus on kavandatud selle tööstuslik kasutamine.

Kuna suured projektid hõlmavad suurt hulka seadmeid, millel olev tarkvara on hajutatud sõlmede, sõlmede ja isegi pilvede vahel, peab selle protsessiga kaasnema täielik dokumentatsioon. Näiteks sisaldab tehniline dokumentatsioon tabeleid serverite, tööjaamade, juurdepääsumeetodite jms aadressidega. Visuaalseks esituseks kasutatakse komponentide diagramme, mis annavad ülevaate võrgusõlmede asukohast, nende interaktsiooni komponentide jaotusest jne. Kuid ikkagi tuleb kindlaks määrata meetmed igasuguste infrastruktuuri muudatuste reguleerimiseks, mis võimaldavad kõrvaldada süsteemi erinevate elementide rikete tagajärjed.

Joonis 19. – Rakendusetapi tehnilise kirjelduse näide

See kõik on äärmiselt oluline, kuna järgmine etapp nendes tegevuskohtades hakkab paljusid spetsialiste juurutus- ja tugimeeskonnast tõrjuma ning nad ei peaks iga kord hankima tööks vajalikku teavet erinevatest, isegi teadlikest allikatest. Seetõttu tuleb dokumentatsiooni hoida ajakohasena ja muuta samaaegselt süsteemi seadistuste muudatustega, arhitektuurse lahenduse muudatustega jne.

Süsteemi tööstuslikuks kasutamiseks on kasulik paigutada katsestendid “lahingu” kohtadesse, simuleerides tegelikule elule lähedast tööd. Noh, äkki tuleb kommentaare, mis nõuavad uute väljaannete avaldamist. Kõik on loomulikult professionaalid, vastutustundlikud inimesed ja kõik muu, kuid siiski on parem käivitada värskendused esmalt katsestendil. Igaks juhuks.

Vahepeal on 90% ajast juba mööda lennanud...

2. Kliendipersonali koolitus infosüsteemiga töötamiseks

Nagu juba korduvalt mainitud, pööratakse suurtes projektides erilist tähelepanu dokumentatsiooni kvaliteedile, sh juhised süsteemi kasutajatele. Kõige sagedamini jagatakse kasutajajuhised segmentideks tegevuse tüübi, spetsialiseerumise jms järgi. See võimaldab teil keskenduda dokumendis olulistele punktidele ja mitte koormata kasutajaid tarbetu teabega.

Kuna koolitusel võib olla kaasatud märkimisväärne hulk erinevaid klienditöötajaid, keda omakorda ei ole võimalik äriprotsesside järjepidevuse tagamiseks korraga koolitada, keda tuleb koolitada erinevate funktsionaalsete kohustuste osas ja muudel mõjuvatel põhjustel, on vaja hoolikalt planeerida personali koolitusprotsessi . Samuti on kasulik jagada õpilased rühmadesse kategooriatesse, mis nõuavad erinevat lähenemist ja õppimise sügavust, lähtudes nende esialgsest valmisoleku tasemest. Sellest tulenevalt tuleb koostatud koolituste ajakava kõigi huvilistega kokku leppida ja tellija juhtkonna poolt kohustuslikuks kinnitada.

Ja hoiatasime juba projekteerimisetapis, et kliendipersonali koolitamine pole mitte ainult väga oluline ülesanne, vaid ka väga töömahukas...

3. Infosüsteemi puuduste ja puuduste tuvastamine

Väga sageli suurte projektide puhul ei võimalda lõpliku väljalaske testimine tuvastada kõiki lahenduse probleemseid kohti. Selle põhjuseks võivad olla: tohutud andmemahud tegelikes lahingutingimustes, ärireeglite ainulaadsete kombinatsioonide ilmnemine reaalsetes äriprotsessides, konkreetsete seadmete tööomadused, süsteemikomponentide spetsiifilised kombinatsioonid, koormuse tasakaalustamine hajutatud sõlmede vahel jne.

Tihti muudab olukorra veelgi keerulisemaks asjaolu, et uute süsteemide kasutuselevõtt algstaadiumis ei välista kuidagi vajadust vanade süsteemide kallal töid teha. See tähendab, et kasutajad dubleerivad andmeid mõlemas süsteemis. Mõnikord tuleb olemasolevaid ajakohaseid andmeid migreerida pärandpoodidest uutesse ning teabe struktuur ja formaat on tavaliselt väga-väga erinev. Näiteks kui uues andmestruktuuris ei ole nõutavate detailide täitmiseks piisavalt teavet, täidetakse need mõnede andmetega, mis on määratud “vaikimisi”, ja seejärel kohandavad kasutajad neid käsitsi. Ja see on vaid väike osa sellest, mida me pärisprojektides kohtame.

Omaette teema on integratsioonilahendused, mille puhul võivad tõrked tekkida ahelas, kasutades erinevaid kahe, kolme või enama meeskonna poolt välja töötatud komponente. Selles olukorras süüdlaste leidmine on äärmiselt keeruline, kuna vead tekivad juurutamise käigus tuvastatud ebakõlade tõttu kõige sagedamini integratsioonielementide ristumiskohas. Ja siin on oluline mitte otsida karistuse eest vastutavaid isikuid, vaid kiiresti ja konstruktiivselt kokku leppida ühendatud komponentide arendajate ühistes järeleandmistes ja probleemi tõhusalt lahendada.

Kõike eelnevat arvesse võttes on proovioperatsiooni etapp kõige sagedamini täis emotsioonipurskeid ja vastastikuseid pretensioone nii arendusmeeskondade vahel kui ka klientidega. Antud juhul on väga oluline arhitektide ja süsteemianalüütikute roll, kes peavad probleemi kiiresti lokaliseerima, lahenduse välja pakkuma ja selle kõigi huvigruppidega kokku leppima. Sellise töö tegemiseks on vaja lisaks esmastele kutseoskustele omada ka läbirääkija annet ja teadmisi juhtimise põhitõdedest.

Vahepeal oleme jõudnud projektile eraldatud aja põhja...

4. Infosüsteemi juurutamise käigus tehtavate muudatuste kooskõlastamine

Kui mõne infosüsteemi funktsionaalmooduli toimimine ei vasta kriitiliselt kliendi vajadustele ja ootustele ning nendest probleemidest ülesaamiseks leitakse lahendused, siis tuleb need fikseerida ja kliendiga kokku leppida.

Uue lahenduse kokkuleppimise etapp on väga oluline vähemalt kahel põhjusel.

Esiteks, kui muudatuste elluviimise maht ületab projektiplaanis sellisteks riskideks ette nähtud summasid, siis tuleb kas sõlmida täiendavad kokkulepped või täitmismeeskond töötab kahjumiga. Tihti kutsutakse esinejaid kiiresti muudatusi tegema, kuid nad ütlevad, et võtame neid arvesse ja maksame nende töö eest hiljem, ühes paketis. Kuid tegelikult viivad sellised juhtumid enamasti selleni, et tellija unustab siis oma lubadused sootuks ja tunnistab tehtud töö teostajapoolseks paranduseks oma vigadest.

Teiseks võivad süsteemi mõne komponendi muudatused kaasa tuua paratamatu muutuse vastastikku sõltuvates komponentides, mis nõuab hoolikat analüüsi ja võib-olla ka terve alamsüsteemide ahela ümberkujundamist. Vastasel juhul on defektide tekkimine süsteemi kui terviku töös vältimatu. See võib väljenduda näiteks külgneva esinejate meeskonna mooduli rikkes ja klient kuulutab nad juba häkkideks ja defektideks. Tõde muidugi selgub, aga piiramine jääb.

Ja parafraseerides Jerzy Leci: "Kui jõudsime ettenähtud aja lõpuni, kostis altpoolt koputus..."

Kuna aeg on möödas, tuleb tellijaga läbi rääkida ja veenda, et temagi ei olnud projektis kingitus ja osa süüst lasub tal.

5. Infosüsteemi viimistlemine lähtuvalt proovitöö tulemustest

Kui proovioperatsiooni käigus tehakse ja lepitakse kokku arendatud tarkvara- ja riistvarakompleksis muudatuste tegemiseks, siis nende põhjal jagatakse teostajatele ülesanded nende elluviimiseks. Korratakse punktis 3. Projektlahenduse elluviimine kirjeldatud protsessi. Aga…

Kui süsteemi projekteerimise etapis arutasime Scrumi metoodika (1) täiemahulise kasutamise negatiivset mõju suurtes projektides, siis praeguses etapis on see igati sobiv. See on eriti märgatav projektides, mille puhul kliendile üleantud toode teda enamikus aspektides ei rahulda. Teisisõnu, on aeg paanikale järele anda ja väga kiiresti, ülepeakaela teha muudatusi juba kasutusel olevas tootes.

Tegelikult on saabunud hetk, mil asjakohased on järgmised tingimused:

1. Klient on juba hakanud süsteemiga reaalselt töötama, tal on selleks aega eraldatud ja ta saab nüüd selgelt aru, mida tal tegelikult vaja on. Sellest tulenevalt on ta valmis tegema tihedat koostööd esinejate meeskonnaga ja tal on selleks kriitiline vajadus;
2. Suures osas on dokumentatsioon juba valmis ning selle muutmist ja täiendamist ei saa enam nii kiiresti läbi viia, vaid vormistada tagantjärele, lähtudes eduka rakendamise tulemustest.
3. Täiustused toimuvad enamasti üksikutes moodulites, alamsüsteemides, ahelates, mille segmendi eest vastutab konkreetne esinejate meeskond. Seetõttu on kasutajate ja arendajate vaheline suhtlus juba lokaliseeritud, kvaliteetset tagasisidet on lihtne luua;
4. Täiustused ja parandused tuleb läbi viia väga kiiresti, väikeste hooga, kusjuures tulemus kandub üle kliendile, kes on nendest eluliselt huvitatud;

Väga oluline on, et lõpuks viiakse projekteerimisdokumentatsioon uuendustega täielikult kooskõlla ning meeskond leiab sealt hõlpsasti asjakohase lahenduse järgnevate muudatuste analüüsimiseks ja kujundamiseks.

Joonis 20. – Infosüsteemi juurutamise etapp

Kommentaarid puuduvad…

6. Infosüsteemi üleviimine kommertskasutusele

Kui proovitöö käigus lahenevad kõik vastuolulised küsimused ja arusaamatused juurutatava süsteemi toimimise ja arenduslepingule vastavuse osas, kirjutavad pooled alla lepingu täitmise aktid. Tellija tasub tehtud tööde eest täies ulatuses. Lepingu infosüsteemi arendamiseks ja juurutamiseks võib lugeda sõlmituks.

Rakendamine liigub tööstusliku käitamise faasi. Need suhted on enamasti õiguslikult reguleeritud eraldi lepingu või lisalepinguga süsteemi tööstusliku toimimise toetamiseks. Selle lepingu raames saab teha ennetavaid töid süsteemi komponentide toimimise, nende koostoimete diagnoosimiseks, väiksemate rikete kõrvaldamiseks jne.

7. Lõigu kokkuvõte

Infosüsteemi juurutamise etapp tähistab kogu selle tootmisprotsessi tõehetke ja tähistab kõigi projektis osalejate jaoks kõige raskema perioodi algust. See võib hõlmata järgmisi tegevusi:

1. Süsteemi juurutamine tööstuslikul käitamiskohas, sealhulgas seadmete tarnimine, süsteemitarkvara paigaldamine, juurutava süsteemi praeguse versiooni paigaldamine jne;
2. Kasutajate koolitamine süsteemiga töötamiseks, sh administraatorid, seadmete hooldusspetsialistid jne.
3. Proovitöö käigus tuvastatud puuduste ja defektide tuvastamine ja kõrvaldamine.
4. Süsteemi toimimise muudatuste koordineerimine ja lepinguliste kohustustega vastavusse viimine;
5. Lepinguliste kohustuste täitmise dokumentide allkirjastamine. Tehtud tööde eest täieliku tasumine;
6. Süsteemi kasutuselevõtt kommertskasutuses;

Rakendamine

Mooduli koodi juurutamiseks on raske nõu anda, kuna igal arendajal on teatud harjumused ja oma koodiarenduse stiil. Projekti elluviimisel on oluline arendusmeeskonna(de) koordineerimine. Kõigile arendajatele kehtivad ranged allikatestide kontrollireeglid. Arendusmeeskond, olles saanud tehnilise projekti, asub mooduleid kodeerima ja sel juhul on põhiülesanne spetsifikatsioonist aru saada. Disainer määrab, mida tuleb teha, ja arendaja määrab, kuidas seda teha.

Arendusetapis on disainerite, arendajate ja testimeeskondade vahel tihe suhtlus. Intensiivse arenduse korral on testija sõna otseses mõttes "pandlaga" arendaja külge, olles tegelikult arendusmeeskonna liige.

Disainer toimib selles etapis "kõndiva teatmeteosena", kuna ta vastab pidevalt arendajate küsimustele tehniliste kirjelduste kohta.

Kõige sagedamini muutuvad kasutajaliidesed arendusetapis. Selle põhjuseks on muuhulgas moodulite perioodiline demonstreerimine kliendile. Andmepäringud võivad samuti oluliselt muutuda.

Tuleb märkida, et kogu projekti kokkupanekuks peab olema spetsiaalne tööruum. Just need moodulid saadetakse testimiseks. Testija ja arendaja vaheline suhtlus ilma projekti osade tsentraliseeritud ülekandmiseta on vastuvõetav, kuid ainult siis, kui on vaja mõnda muudatust kiiresti kontrollida. Väga sageli on arendusetapp ja testimise etapp omavahel seotud ja jooksevad paralleelselt. Veajälgimissüsteem sünkroonib testijate ja arendajate tegevusi.

Arenduse käigus tuleks korrastada pidevalt uuendatavad valmisprojekti moodulite hoidlad ja moodulite komplekteerimisel kasutatavad teegid. Soovitatav on, et salvestusruumi värskendamise protsessi juhiks üks inimene. Üks hoidlatest peaks olema funktsionaalse testimise läbinud moodulite jaoks ja teine ​​​​ühenduvustesti läbinud moodulite jaoks. Esimene neist on mustandid. Teine on midagi, millest on juba võimalik süsteemi jaotuskomplekti kokku panna ja seda kliendile kontrolltestide tegemiseks või mis tahes tööetappide läbimiseks demonstreerida.

Dokumentatsioon luuakse kogu arendusprotsessi jooksul. Kui moodul on lingitestimise läbinud, saab seda dokumentatsioonis kirjeldada. Kui moodulid muutuvad sageli, algab kirjeldus alles siis, kui moodul muutub enam-vähem stabiilseks.

Disainitulemuste töötlemine

Arendamisetapis kontrollitakse reeglina uuesti funktsioonide aatomilisust, aga ka dubleerimise puudumist.

On soovitav, et projekteerimisetapis oleks "funktsioon-üksuse" maatriks juba ehitatud. See on sisuliselt formaliseeritud esitus sellest, mida ettevõte üritab teha (funktsioonid) ja millist teavet on vaja tulemuse (üksus) saavutamiseks töödelda. Selline maatriks võimaldab teil kontrollida järgmisi punkte:

• kas igal olemil on konstruktor – funktsioon, mis loob olemi eksemplare (loo);
• kas sellele olemile on viiteid, st kas seda olemit kasutatakse kuskil (viited);
• kas selles olemis on muudatusi (värskendus);
• kas igal olemil on destruktor – funktsioon, mis kustutab olemi eksemplare (delete).

Sageli täidab hävitaja rolli andmearhiveerimisprogrammide komplekt. Sageli infosüsteemides info lihtsalt koguneb. See on lubatud ainult siis, kui kogu teabe kogumise perioodi (ja tegelikult ka kogu infosüsteemi eluea) jooksul vastavad selle toimivusnäitajad kliendi nõudmistele. Praktikas on see äärmiselt haruldane kokkusattumus. See on peamiselt tingitud töödeldud teabemahtude kasvust. Tuleb märkida, et sel juhul ei saa te loota ainult DBMS-i või riistvara võimsusele, kuna sellised ulatuslikud tootlikkuse suurendamise meetodid annavad väikese hinnangulise kiiruse kasvu. Tegelikult on kõige tõenäolisem testimisülesanne reageerida süsteemile või selle üksikutele osadele töödeldud andmete mahu suurenemisele. Sel juhul loob testimisrühm mooduli (isegi abstraktsete) andmete genereerimiseks, valib päringute komplekti, mille kiirusomadused on kriitilised, seejärel teostab mõõtmised ja joonistab iga päringu puhul täitmiskiiruse sõltuvuse andmemahust. . Selline lihtne toiming võimaldab teil vältida tõsiseid vigu nii infosüsteemi kujundamisel kui ka rakendamisel.

Moodulite spetsifikatsioon peab valmima projekteerimisetapis, mida reaalsetes projektides sageli lihtsalt ei tähtsustata. Ja asjata – sest moodulite läbimõtlematu rakendamise tõttu võivad andmebaasi skeemi kõik eelised kaduda. Seega, jättes tähelepanuta mooduli spetsifikatsioonid, võite infosüsteemi sisestada:

• andmemahtude kontrollimatu kasv;
• päringute lõimed, millel on oma olemuselt suur konflikti tõenäosus, või päringute lõimed, mis töötavad "igavesti" (katse käivitada lõime, tuvastada konflikt ja tühistada kõik toimingud, proovige uuesti jne) nendega vastuolus olevate lõimede tõttu;
• segamissüsteem ja liidesemoodulid;
• moodulite dubleerimine;
• vead äriloogika paigutuses;
• kliendi poolt nõutud süsteemi funktsioonide rakendamata jätmine või mittetäielik rakendamine.

See ei ole täielik loetelu probleemidest, mis avastatakse kas põhjaliku testimise etapis või süsteemi kasutuselevõtmisel ja võib-olla isegi süsteemi töötamise ajal (kui mooduleid hakatakse tegelikult kasutama).

Lisaks ei võimalda mooduli spetsifikatsioonide puudumine täpselt hinnata iga mooduli keerukust ja selle tulemusena määrata mooduli loomise järjekorda ega jaotada õigesti personalikoormust. Tavaline olukord sellisel juhul on “keegi ootab kedagi”, infosüsteemi loomise protsess aga seisab.

Süsteemi moodulid

Sageli peate arvestama suure hulga teenindus- või abiprotsessidega, mis ei ole sõnastatud ärifunktsiooniga otseselt seotud. Reeglina on need igas infosüsteemis leiduvad süsteemifunktsioonid, näiteks:

• järjekorrahaldur või ülesannete planeerija;
• prindihaldur;
• tööriistad andmetele juurdepääsuks ja ad hoc päringute loomiseks (sageli on need aruannete generaatorid);
• kataloogide ja muude failisüsteemi ressursside haldamine;
• automaatne varundamine;
• automaatne taastamine pärast süsteemi riket;
• vahendid kasutajate juurdepääsu reguleerimiseks süsteemile (mis koosnevad kasutajate loomise vahenditest ja vahenditest neile õiguste määramiseks);
• tööriist infosüsteemi kasutajale keskkonna seadistamiseks;
• vahend, mille abil kasutaja saab muuta oma seadeid (sh parooli);
• rakenduste haldamise tööriist;
• infosüsteemi administraatori keskkond.

Mõnda neist funktsioonidest peab täitma operatsioonisüsteem, kuid kui see töötab heterogeenses keskkonnas, siis pole mingit garantiid, et kasutajatele meeldivad erinevad liidesed erinevates operatsioonisüsteemides. Ideaalis peaksid kõik kliendirakendused töötama samas operatsioonisüsteemis, kuid praktikas peavad arendajad kliendi juures sageli tegelema terve erinevate tööjaamade “loomaaiaga” – see on mitme äri automatiseerimiskatse tulemus. Arendaja eesmärk on viia süsteem võimalikult homogeensesse olekusse või muuta vähemalt lõppkasutajate tööjaamad sarnaseks.

Infosüsteemi loomise ülesanne heterogeenses keskkonnas tõstab oluliselt nõudeid koodiarendajatele ja valitud arendustööriistale. See kehtib eriti süsteemimoodulite arendamise kohta. Tähelepanu tuleks pöörata moodulitele, mille koodi juurutamine sõltub operatsioonisüsteemist. Sellised moodulid tuleb eraldada iga operatsioonisüsteemi jaoks eraldi rühmadesse, näiteks Win98, WinNT jne. Iga rühma moodulitel peavad olema ranged vahetusliidesed – nende edastatavad ja vastuvõetavad andmed on rangelt määratletud ning iga kõrvalekaldumine spetsifikatsioonist on karistatav. Ükski moodul väljaspool seda rühma ei saa kasutada muid kõnesid peale vahetusliideste. Sel viisil isoleeritakse operatsioonisüsteemist sõltuvad moodulid teistest moodulitest.

Üldiselt vähendab süsteemimoodulite isoleerimine nende sideliideste range reguleerimise kaudu oluliselt veaparanduse ja süsteemitoe kulusid. Lisaks muudab see testimise lihtsamaks, nimelt vigade tuvastamise ja silumise. Probleemi teine ​​pool on see, et nõuded süsteemimooduli vahetusliidese koodile kasvavad järsult. See on see, mis silutakse kõigepealt ja see peaks töötama väga selgelt.

Infosüsteemide jälgimise tööriistad

Kui infosüsteem on mahukas, siis tuleks kaaluda selle haldamist ühest tööjaamast. Hoolitseda tuleb mitte ainult infosüsteemi lõppkasutaja, vaid ka seda teenindava personali eest. Erilist tähelepanu tuleks pöörata infosüsteemi kriitiliste kohtade jälgimisele, kuna riket on sageli lihtsam ennetada kui selle tagajärgi parandada. Järelevalve all mõeldakse neid ülesandeid, mille lahendamise vajadusele tellija reeglina ei mõtle ja mis analüütilises uuringus ja isegi projekteerimisel enamasti puuduvad. Vajadus seirevahendite järele tuleb ilmsiks alles süsteemi kasutuselevõtu etapis ning see vajadus on seda suurem, mida keerulisem on süsteem ja mida kriitilisemaid sektsioone see sisaldab.

Arendajad ja disainerid peaksid hindama süsteemi keerukust. Kui otsustatakse koostada terviklik haldus- ja seiretööriist, mida tehnilistes kirjeldustes ette nähtud ei ole, siis sel juhul tuleks tehnilisi kirjeldusi muuta, mitte järgida kliendi eeskuju. Keerulises süsteemis peate ikkagi kriitilisi protsesse jälgima. Selliseid tööriistu on väga keeruline valmissüsteemi sisse viia, kuna monitorid saavad sageli algandmeid üsna madala tasemega süsteemimoodulitelt. Tõenäoliselt pole see võimalik ilma andmebaasi skeemi muutmiseta ja pole garantiid, et selline muudatus ei halvenda süsteemi jõudlust.

Monitoride arendamine on üsna spetsiifiline ülesannete klass: ühelt poolt peavad need töötlema piisavas koguses informatsiooni, teisalt ei tohi need oluliselt mõjutada infosüsteemi teiste komponentide tööd. See sunnib arendajaid monitoride kujundamisel ja oma moodulite koodide väga hoolikalt kirjutamisel olema eriti ettevaatlik.

Liidesed

Lõppkasutaja liidesed on need, mida klient kõige rohkem kritiseerib, tulenevalt sellest, et just neid infosüsteemi osi oskab ta enam-vähem asjatundlikult hinnata – tavaliselt on need ainsad, mida ta näeb. See tähendab, et liidesed on juurutamisetapis infosüsteemi kõige sagedamini muudetav element.

Infosüsteemi sageli muudetavad komponendid tuleks eraldada harva muudetavatest komponentidest, et mõned muudatused ei tooks kaasa teisi. Üks sellise isoleerimise tehnika on andmepäringute eraldamine liidesest järgmiselt.

• iga päring on kodeeritud identifikaatoriga või "suletud" konkreetse süsteemi funktsiooniga;
• liidese arendaja ei tea andmepäringust midagi peale valikuatribuutide parameetrite - nende tüübi ja võimalusel ka valiku ridade arvu;
• vigade käsitlemine andmepäringutes on eraldi moodul;
• Eraldi moodul on ka vigade käsitlemine päringu tulemuse tõlgendamisel.

Andmepäringute tulemuste töötlemisel tuleks erilist tähelepanu pöörata ka hostkeele tüüpide ja DBMS-i vahelise vastavuse küsimustele, sealhulgas numbritüüpide täpsuse küsimustele, kuna nende esitus on erinevates DBMS-ides oluliselt erinev. Samuti pidage meeles andmepäringuid, mis kasutavad operatsioonisüsteemispetsiifilisi funktsioone, nagu atribuudi väärtuse bait- ja sõnafunktsioonid (nt need funktsioonid töötavad Inteli ja SUN SPARC-i puhul erinevalt). Andmetüüpe saab üle kanda kas otse päringus, kasutades ülekandefunktsioone ja DBMS-i sisseehitatud funktsioone, või rakendusprogrammi funktsioonides. Mitte kõigi DBMS-ide puhul ei anna kaudne tüübikonversioon sama tulemust, seega kui infosüsteem kasutab andmeid mitmest andmebaasist, mida haldavad erinevad DBMS-id, siis on parem kaudseid tüübikonversioone vältida.

Samuti peaksite kehtestama üsna ranged reeglid kasutajaliideste välimusele. Infosüsteemi kõigi komponentide jaoks tuleks luua ühtse stiili mulje.

Andmebaasi versioonid

Enamikul juhtudel luuakse projekti andmebaasi esimene versioon üsna kiiresti - see on täielikult normaliseeritud struktuuri rakendamine, mis saadakse analüüsi etapis. Selle andmebaasi põhieesmärk on pakkuda arendajate ja disainerite prototüüpe, demonstratsioone ja mõningaid katseid.

Andmebaasi loomise ja selle algusandmetega täitmise skriptid on ühtlasi infosüsteemi lähtekoodiks ning sellele kehtivad versioonikontrolli reeglid. Tuleb märkida, et andmebaasi versioonide haldamine skripti tasemel on endiselt lihtsam kui DBMS-i enda pakutavate andmete mahalaadimise ja laadimise tööriistade tasemel, kuna enamikul juhtudel ei suuda sellised tööriistad pakkuda mitmeid lihtsaid, kuid vajalikke funktsioone:

• kontrollida, millised andmeobjektid ja andmed toimuvad laadimisobjektides A ja B ning laadida andmebaasi ainult A ja B “erinevus” (teosta versiooniuuendus);
• kontrollige, kas üleslaadimisobjektides C ja D toimuvad muudatused ei ole vastuolus üleslaadimisobjektiga A (ühendage versioonid).

CASE-tööriistadel on andmebaasi skeemi versioonikontroll ja mõnel on sätted, mis võimaldavad teil juhtida ka käivitusandmeid. See võimaldab neid tööriistu kasutada andmebaasi versioonikontrolli pakkumiseks.

Usaldusväärsem on juhtida päästikute ja salvestatud protseduuride lähtekoodi versioone, kasutades sama versioonikontrollisüsteemi, mida kasutatakse projekti enda lähtekoodi salvestamiseks.

Töötlemisloogika paigutus

Üheks oluliseks disainiprobleemiks on andmetöötluse äriloogika paigutamise viis: paigutada see (ja milline osa) kas serverisse salvestatud protseduuride, pakettide, trigerite, muude terviklikkuse piirangute kujul otse andmebaasiserverisse või funktsioonide kujul kliendil (klienditarkvaras). Liidesereeglite ja andmereeglite asukoht on täpselt määratud: esimesed asuvad alati kliendil, teised serveris. Kaasaegsetes DBMS-ides saab äriloogika reegleid paigutada nii kliendile kui ka serverile. Vaatame ühte näidet lihtsast ärireeglist:

• Kuvaväljal oleva väärtuse sisestab kasutaja, mitte ei vali seda loendist, kuid kehtivate väärtuste komplekt on rangelt piiratud (näiteks kaks või kolm erinevat väärtust).

Ühest küljest nõuab kasutaja süsteemilt viivitamatut reageerimist andmesisestusveale, teisest küljest on andmebaasiväljal määratud väärtustest erinevad väärtused (kaks või kolm) vastuvõetamatud. Sellises olukorras on tegelikult vaja järgida kahte reeglit. Andmete reegel korraldatakse sel juhul kontrollpiirangu kujul ja liidese reegel, mis keelab sisestada muid väärtusi kui määratud, kordab täpselt andmereeglit, kuid seda rakendatakse kasutajaliidese tasemel. Näib, et sellisel juhul on loendiga vormi rakendamine ideaalne lahendus, kuid enamik operaatoreid eelistab vormis olevat tüüpi, eriti kui sisendväärtuse pikkus on väike. Suure loendite arvuga vorme on lõppkasutajate jaoks üsna raske töödelda. Vormi väärtuste komplekti puhul tuleks samuti hoolitseda selle eest, et rakenduseprogrammi liidese tasemel teisendataks märgistringide (kui suurtähtede tähtsus ei ole) suur- või väiketähtedeks.

Mallid

Mallide ja teekide kasutamine "sarnaste" moodulite loomiseks on üsna tavaline praktika. Mida sel juhul kasutada – objekte ja klasse või teeke – otsustab konkreetne arendajate rühm. Enamasti on arendusmeetodi dikteerimine mõttetu, sest arendaja kirjutab koodi nii, nagu ta oskab või on harjunud. Neid hetki kontrollib tavaliselt projektijuht.

Igas projektis on koodi kopeerimine keelatud, kuna see toob kaasa sama koodi erinevate versioonide ilmumise rakendusprogrammi erinevatesse fragmentidesse ning selle tulemusena raskesti tuvastatavaid ja parandatavaid vigu. Tuleks kehtestada range reegel: kasutatakse funktsioonikutset, mitte selle koopiat koodis; iga kõrvalekalle sellest reeglist on karistatav.

Testimine

Nagu eespool mainitud, saab testimisrühmi kaasata juba projekti arendamise algfaasis. Põhjalik testimine ise tuleks tõesti eraldada eraldi arendusfaasiks. Olenevalt projekti keerukusest võivad testimised ja veaparandused võtta kolmandiku, poole või rohkemgi kogu projekti arendusajast.

Mida keerulisem on projekt, seda suurem on vajadus vigade jälgimise süsteemi automatiseerimiseks. Selline süsteem pakub järgmisi funktsioone:

• veateate salvestamine (koos kohustusliku teabega selle kohta, millise süsteemikomponendiga viga on seotud, kes selle leidis, kuidas seda reprodutseerida, kes vastutab selle parandamise eest ja millal see tuleks parandada);
• teavitussüsteem uute vigade ilmnemise, teadaolevate vigade oleku muutumise kohta süsteemis (reeglina on need teated e-posti teel);
• aruanded jooksvate vigade kohta süsteemikomponentide, ajavahemike, arendusgruppide ja arendajate kaupa;
• teave vea ajaloo kohta (sh sarnaste vigade jälgimine, vea kordumise jälgimine);
• teatud kategooriate vigadele juurdepääsu reeglid;
• infosüsteemi lõppkasutaja piiratud juurdepääsu vigade jälgimise süsteemile liides, mida kasutatakse kasutaja ja süsteemi tehnilise toe vahelise teabevahetuse liidesena.

Sellised süsteemid kõrvaldavad paljud organisatsioonilised probleemid, eriti automaatse veateavituse.

Süsteemi testid ise võib jagada mitmesse kategooriasse:

• autonoomsed moodulite testid - kasutatakse juba süsteemikomponentide arendusfaasis ja võimaldavad jälgida üksikute komponentide vigu;
• süsteemi komponentide ühendustestid - kasutatakse nii arendusetapis kui ka testimise etapis ning võimaldavad jälgida süsteemi komponentide vahelist korrektset koostoimet ja infovahetust;
• süsteemi test on süsteemi aktsepteerimise peamine kriteerium. Reeglina on see testide rühm, mis sisaldab autonoomseid teste ning ühendusteste ja mudeleid. See test peab reprodutseerima süsteemi kõigi komponentide ja funktsioonide tööd, selle põhieesmärk on süsteemi sisemine aktsepteerimine ja selle kvaliteedi hindamine;
• vastuvõtutest – kasutatakse süsteemi kliendile üleandmisel. Siin alandavad arendajad sageli süsteeminõudeid võrreldes süsteemitestiga ja üldiselt on selge, miks see õigustatud on;
• jõudlus- ja koormustestid sisalduvad süsteemi testis, kuid väärivad eraldi äramärkimist, kuna see testide rühm on peamine süsteemi töökindluse hindamisel.

Iga rühma testid hõlmavad tingimata rikete modelleerimise teste. Siin kontrollitakse komponendi, komponentide rühma või süsteemi kui terviku reaktsiooni järgmist tüüpi riketele:

• infosüsteemi eraldi komponendi rike;
• infosüsteemi komponentide rühma rike;
• infosüsteemi põhimoodulite rike;
• operatsioonisüsteemi rike;
• "kõva" rike (voolukatkestus, kõvaketta rike).

Need testid võimaldavad hinnata infosüsteemi õige oleku taastamise alamsüsteemi kvaliteeti ja olla peamise teabeallikana strateegiate väljatöötamisel, et vältida tööstusliku töö käigus tekkivate rikete negatiivseid tagajärgi. Tavaliselt on see testide klass, mille arendajad eiravad ja seejärel võitlevad tootmissüsteemi tõrgete tagajärgedega.

Infosüsteemide testimisprogrammi teine ​​oluline punkt on testandmete generaatorite kättesaadavus. Neid kasutatakse nii süsteemi funktsionaalsuse testide, süsteemi töökindluse testide kui ka süsteemi jõudluse testide läbiviimiseks. Infosüsteemi jõudluse sõltuvuse tunnuste hindamise ülesannet töödeldava teabe mahtude kasvust ei saa lahendada ilma andmegeneraatoriteta.

Kasutamine ja hooldus

piinamise ärakasutamine alistab testimisprotsessi. Reeglina ei võeta süsteemi täielikult kasutusele, järk-järgult.

Kasutuselevõtt läbib vähemalt kolm etappi:

teabe kogumine;

projekteerimisvõimsuse saavutamine.

Info esialgne laadimine algatab üsna kitsa vigade ringi – peamiselt on tegemist andmete mittevastavuse probleemidega laadimise ajal ja laadijate enda vigadega ehk sellega, mida testiandmetes ei jälgitud. Sellised vead tuleb võimalikult kiiresti parandada. Ärge olge laisk, et installida süsteemi silumisversiooni (kui teil on muidugi lubatud juurutada kogu tarkvara, mis kaasneb infosüsteemi silumisega kohapeal). Kui reaalajas andmete silumine on võimatu, peate olukorda simuleerima ja kiiresti. Selleks on vaja väga kvalifitseeritud testijaid.

Info kogumise perioodil ilmneb kõige rohkem infosüsteemi loomisel tehtud vigu. Reeglina on need mitme kasutaja juurdepääsuga seotud vead. Sageli ei pöörata sellistele vigadele testimisetapis piisavalt tähelepanu – ilmselt modelleerimise keerukuse ja protsesside automatiseerimise tööriistade kõrge hinna tõttu. testimine infosüsteem mitme kasutaja juurdepääsu tingimustes. Mõnda viga on üsna raske parandada, kuna need on disainivead. Ükski hea projekt pole nende eest kaitstud. See tähendab, et igaks juhuks tuleb selliste vigade lokaliseerimiseks ja parandamiseks aega varuda.

Teabe kogumise perioodil võite kohata kuulsat "baas on langenud". Halvimal juhul selgub, et DBMS ei pea infovoogudele vastu. Kui see on hea, on konfiguratsiooniparameetrid lihtsalt valed. Esimene juhtum on ohtlik, kuna DBMS-i tootjat on üsna raske mõjutada ja kliendile ei meeldi lingid DBMS-i tehnilise toe teenusele. DBMS-i rikke probleemi ei pea lahendama mitte tootja, vaid teie - muutke skeemi, vähendage päringute voogu, muutke taotlusi ise; üldiselt - valikuid on palju. Hea, kui baasi taastumisaeg mahub planeeritule.

Süsteemi projekteerimisvõimsuse saavutamine asjaolude edukas kombinatsioonis tähendab mitmete väiksemate ja mõnikord tõsiste vigade parandamist.

Muud rakenduste arendamise lähenemisviisid

Tavaliselt usuvad lõppkasutajad ja juhtkond, et disainiprotsess ei ole andnud tulemusi, kuna puuduvad valmiskomponendid, mida "puudutada". Tihti nõuab klient projekti elluviimise etapi ennetähtaegset läbiviimist, et saada mingi tulemus ja seda võimalikult kiiresti demonstreerida. Sel juhul on väga ahvatlev valida kiirendatud rakenduste arendus (AAD) või koostöörakenduste arendus (CAD). Sellised meetodid hõlmavad töötava prototüübi väljatöötamist ja seejärel selle kasutajatele demonstreerimist. Kasutajad kommenteerivad, mis neile meeldib ja mis mitte. Disainer täpsustab prototüüpi, võttes arvesse tehtud kommentaare, ja demonstreerib seejärel uuesti, mis juhtus. Ja nii edasi. Protsessi korratakse, kuni kasutajatele meeldib see, mida nad näevad ja prototüübist saab töötav rakendus. Tavaliselt on ajapiirang ja iteratsioonide arv, vastasel juhul täiustavad kasutajad prototüüpi igaveseks. Teoreetiliselt võimaldab see hankida süsteemi, mida kasutajad nõuavad. Praktikas tekitab selline lähenemine rakenduste arendamisele tõsiseid probleeme.

• Kogu tähelepanu on suunatud ekraanivormidele ning andmetöötluse reeglite ja süsteemi funktsioonide osas jääb kulisside taha. Tekib kiusatus alustada tööd aruannetega, samas kui aruanne ei ole algtoode, vaid infosüsteemi tuletistoode.
• Kasutajad eeldavad, et kui prototüübi versioon on kokku lepitud, siis on moodul valmis. Tegelikult võib see olla lihtsalt pilt, millel on süsteemi funktsioonide helistamiseks ja teiste moodulitega suhtlemiseks mõeldud „stubpide“ komplekt.
• Moodulid on disainitud üksteisest isoleeritult (enamus teist on ilmselt kokku puutunud raamatupidamisprogrammidega, kus iga tööjaam on autonoomne ja funktsioonid sageli dubleeritud). Selle tagajärjeks on vastuolud moodulite vahel, funktsioonide ja andmete dubleerimine, mida saab tuvastada vaid moodulite komplekti testides.
• Funktsionaalsust laiendatakse paralleelselt mitmes suunas, mis tähendab, et andmebaasi struktuuri tuleb rangelt kontrollida. DRM-iga muutub andmebaasi skeem prügimäeks, kus tabelid visatakse kiiruga kokku, mille tulemuseks on vastuoluliste ja dubleerivate andmete kogum.
• URP-meetodi kasutamisel dokumenteerimine reeglina puudub või pigem unustatakse süsteemi dokumenteerimise vajadus, kuna luuakse illusioon, et kasutaja saab juba toimuvast aru. Kui rakendus hakkab töötama teistmoodi, kui kasutaja eeldab, tekib palju probleeme.
• Erandolukordi käsitletakse iga mooduli puhul erinevalt.
• Terviklik süsteem reeglina ei tööta, tõenäoliselt on see teatud komplekt automatiseeritud tööjaamu, mis on kiiruga ühendatud.

URP- ja SRP-meetodeid ei saa alati kasutada, kuid ainult siis, kui:

• Projekti ulatus ja ärinõuded on selgelt määratletud, ei muutu ja projekt ise on väike;
• projekt ei sõltu muudest äriautomaatika tööriistadest, väliste liideste arv, millega tuleb tegeleda, on piiratud;
• süsteem on keskendunud ekraanivormidele, andmetöötlus ja süsteemifunktsioonid moodustavad ebaolulise osa, ekraanivormide mugavus on üks viiest kõige olulisemast projekti õnnestumise tegurist;
• kasutajad on kõrgelt kvalifitseeritud ja hindavad uue tarkvara loomise ideed a priori positiivselt.

Sellegipoolest on parem välja töötada projekti väikesed ja eelistatavalt autonoomsed osad URP-meetodi abil.

Praegu on püütud kasutusele võtta veel üks võimalus kiireks projekti kirjutamiseks – äärmuslik programmeerimismeetod. Selle lähenemisviisi põhimõtteid käsitletakse allpool.

Planeerimismäng. Klient määrab programmeerijate poolt antud hinnangute põhjal süsteemi versioonide funktsionaalsuse ja juurutusperioodi. Programmeerijad rakendavad ainult neid funktsioone, mis on antud iteratsioonis valitud funktsioonide jaoks vajalikud.

Selle otsuse tulemusel jääb süsteemi arendus “kulisside taha”, mistõttu arenduse käigus tekib vajadus “stubide” ehitamiseks ja koodi ümberkirjutamiseks. Jääb arusaamatuks, miks teostuse tähtaja määrab tellija, sest tegelikult on see projekteerimismeeskonna otsene vastutus. Tellija saab üldjuhul väljendada ainult oma soove tähtaegade osas ("Soovin seda selliseks ja selliseks kuupäevaks"), kuid tähtaja saab määrata ainult projekteerija ("seda saab teha mitte vähem kui sellisel ja sellisel ajal". aeg”).

Versioonide sagedane muutmine (väikesed väljaanded). Süsteem võetakse kasutusele mõne kuu jooksul pärast rakendamise algust, ootamata kõigi tõstatatud probleemide lõplikku lahendamist. Uusi versioone saab välja anda ajavahemike järel alates päevast kuni kuuni.

Kõik on hea, välja arvatud üks asi: sellisel perioodil on võimatu testida enam-vähem keerulist komponenti. Klient tegutseb tegelikult beetatestijana. Sel juhul näeb ta, et arendajad teevad kõvasti tööd ja isegi parandavad vigu. Küll aga tekivad mõistlikud küsimused: kas tasub tellijat tööprotsessi tutvustada ja kas on vaja läbi viia töösüsteemi katseid? Lisaks eeltoodule tuleb märkida, et sellist põhimõtet ei rakendata tõenäoliselt projekti osade puhul, mis nõuavad ööpäevaringset tööd.

Metafoor. Süsteemi üldine välimus määratakse metafoori või metafooride kogumi abil, mille kallal klient ja programmeerijad koos töötavad.

Ühest küljest tundub see postulaat päris hea, aga teisest küljest, kas klienti on mõtet algatada arendusgrupi siseasjadesse? See, mis puudutab üldilmet (liidesed, aruanded jne), võib tõepoolest kuuluda kliendi pädevusse, kuid kui rääkida teatud komponentide teostuse spetsiifikast, siis vaevalt saab klient oma vajalike teadmiste puudumise tõttu kasulik olla. .

Lihtne disain. Arendatud süsteem teostab igal ajahetkel kõik testid ja toetab kõiki programmeerija poolt määratletud seoseid, sellel ei ole koodiduplikaate ning see sisaldab minimaalset võimalikku arvu klasse ja meetodeid. Seda reeglit võib lühidalt väljendada järgmiselt: "Formuleerige iga mõte üks kord ja ainult üks kord."

See idee on ka hea, aga ei lähe päris kokku koodi kiire kirjutamise põhimõttega. Võib-olla tuleks kõigepealt mõelda, kuidas teha see või teine ​​moodul, moodulite rühm ja alles siis hakata koodi kirjutama?

Testid. Programmeerijad kirjutavad kogu aeg ühikuteste. Kokkuvõttes peaksid need testid õigesti töötama. Iteratsiooni etappide jaoks kirjutavad kliendid funktsionaalseid teste, mis peavad samuti õigesti töötama. Praktikas pole see aga alati saavutatav. Õige otsuse tegemiseks peate mõistma, kui palju maksab teadaoleva defektiga süsteemi tarnimine, ja võrdlema seda vea parandamise edasilükkamise kuludega.

Kui teste kirjutavad programmeerijad ise (eriti ületunde tehes), ei ole need testid täielikult funktsionaalsed ega arvesta kindlasti mitme kasutaja töö iseärasusi. Arendajatel ei ole tavaliselt piisavalt aega täpsemate testide jaoks. Muidugi saab ehitada arendussüsteemi nii, et kõigega tegelevad samad inimesed, kuid siiski ei tasu projekti muuta telesaate “Oma režissöör” analoogiks. Eelnevale on vaja lisada, et süsteemi testimine ei piirdu ainult komponentide (ühikute) testimisega; Vähem olulised pole ka nendevahelised koostoimetestid ja sama kehtib ka usaldusväärsuse testide kohta. Sellegipoolest ei näe äärmuslik programmeerimismeetod ette selle klassi testide loomist. Seda seletatakse asjaoluga, et sellised testid ise võivad kujutada üsna keerulist koodi (see kehtib eriti testide kohta, mis simuleerivad süsteemi reaalset tööd). See tehnoloogia ei võta arvesse ka teist olulist testide klassi - süsteemi käitumise teste, kui töödeldava teabe maht suureneb. Suure versioonimuutuste kiiruse korral on sellise testi tegemine tehnoloogiliselt võimatu, kuna selle rakendamiseks on vaja stabiilset ja muutumatut projektikoodi näiteks nädala jooksul. Sellised tähtajad ei ole üldiselt garanteeritud, kuna versioonid muutuvad sageli. Sel juhul peate kas peatama komponentide arendamise või looma testi ajal projekti paralleelversiooni, mis jääb muutumatuks, teine ​​aga muutub. Seejärel peate läbi viima koodide ühendamise protsessi. Kuid sel juhul tuleb test uuesti luua, kuna äärmuslikud programmeerimismeetodid lihtsalt ei näe ette selliste tööriistade väljatöötamist, mis võimaldavad ennustada süsteemi käitumist teatud muudatuste korral.

Süsteemi ümberkujundamine. Süsteemi arhitektuur areneb pidevalt. Praegust projekti muudetakse, tagades samas kõigi testide korrektse läbiviimise.

Siit saab alguse lõbus. Extreme Programming põhineb eeldusel, et seda on alati võimalik uuesti teha ja seda ilma suuremate kulutusteta. Praktika näitab aga vastupidist.

Paari programmeerimine. Kogu projekti koodi kirjutavad kaks inimest, kes kasutavad sama töölauasüsteemi.

Tekib küsimus: kas keegi on näinud kahte täiesti identset programmeerijat, kellest igaühel oleks tööpäeva lõpus aega oma partnerile dokumentatsiooni kirjutada? Kas on võimalik leida kaksikprogrammeerijaid, kes kõiges ühel meelel?

Ja mis kõige tähtsam, milleks meil sellist programmeerijapaari vaja on? Üldjoontes on põhjus lihtne: kõik ei pea vastu ekstreemse programmeerimise sunnitud kõrgele töötempole ja personali väljavool on vältimatu. Selline paar võib anda mingisuguse kindlustuse – kui üks lahkub, siis võib-olla näeb teine ​​töö lõpuni. Tõsi, ülejäänu jääb veelgi kitsamasse ajaraami - töömaht jääb ju samaks ja varukoopiat vähemalt mõneks ajaks ei tule. Järgneb loomulik protsess teabe edastamiseks uude alaõppesse, mis võtab jällegi aega. Ja nii lõputult.

Pidev integreerimine. Uus kood integreeritakse olemasolevasse süsteemi mõne tunni jooksul. Pärast seda koondatakse süsteem uuesti ühtseks tervikuks ja kõik testid viiakse läbi. Kui vähemalt ühte neist ei tehta õigesti, siis tehtud muudatused tühistatakse.

See postulaat on vähemalt vastuoluline, kuna pole selge, kes parandab vead, mitte ainult kohalikud, vaid ka indutseeritud vale kood. Keerulisi teste pole ju selles etapis ette näha, lisaks jäävad muudatused alles ka vea avastamisel. Samal ajal ei näe äärmusliku programmeerimise meetod ette vigade jälgimise süsteemi.

Kollektiivne omand. Igal programmeerijal on võimalus igal ajal süsteemi mis tahes osa koodist täiustada, kui ta seda vajalikuks peab.

Kas see ei tuleta teile anarhiat meelde? Kuidas sel juhul muudatuste autorit leida? Kas keegi on suure projekti arendamise käigus kohanud sellist “kõigi ametite tungra” ja kaua selline “meistrimees” oma töös vastu peab? See on õige, mitte liiga kaua.

Kohapealne klient. Klient, kes on süsteemiga töötamise perioodil osa arendusmeeskonnast.

See on muidugi hea, aga eesmärk on ebaselge: kas valgustada klienti asja olemusest või teha temast kaasautor? On ebatõenäoline, et ainult kliendil on nii kõrge kvalifikatsiooniga spetsialist.

40-tunnised nädalad. Ületunnitöö kestus ei tohi ületada ühte töönädalat. Isegi üksikud ületunnitöö juhtumid, mida korratakse liiga sageli, on märk tõsistest probleemidest, mis nõuavad viivitamatut tähelepanu.

Nagu näitab ekstreemprogrammeerimise kasutamise praktika (vaatamata mitmetele selle meetodi pooldajate toodud positiivsetele näidetele), on selle lähenemise korral ületunnitöö reegel, mitte erand ning probleemidega võitlemine on sel juhul pidev nähtus. See intensiivistub perioodil, mil toote praegune toorversioon asendatakse teise, jällegi toorversiooniga. Protsessi algatatud klient kogeb enda peal kõiki süsteemivigade ilmnemise rõõme. Kui kauaks teie arvates kliendil sellises olukorras kannatust jätkub? Ta vajab süsteemi toimimiseks...

Avatud tööruum. Arendusmeeskond asub suures ruumis, mida ümbritsevad väiksemad ruumid. Tööala keskele on paigaldatud arvutid, millel töötavad programmeerijate paarid.

Pealegi peaks see kõik eelmiste põhimõtete järgi asuma kliendi territooriumil, kuna ta on arendusprotsessis väga aktiivselt kaasatud. Tekib küsimus: kas selline õnnelik juhus on tõeline?

Ei midagi muud kui lihtsalt reeglid. Ekstreemse programmeerimistehnoloogiaga töötavad meeskonnaliikmed kohustuvad järgima antud reegleid. Need pole aga midagi enamat kui reeglid ja meeskond võib neid igal ajal muuta, kui tema liikmed on saavutanud tehtud muudatuste osas põhimõttelise kokkuleppe.

Võib-olla töötatakse lõpuks välja üks kasulik reegel: "kõigepealt mõtle, siis tee." Sel juhul on muster, mis on väga sarnane kosele. Ekstreemprogrammeerimise pooldajad on millegipärast veendunud, et “juga” ja selle kloonide kasutamisel peab arendustsükkel olema pikk. Pole selge, mis sellist enesekindlust põhjustab. Ei ole ju keelatud projekti etappideks jaotada. Millegipärast arvatakse, et planeerimine on tingimata ühekordne ja muutumatu, kuigi tegelikult see ei vasta tõele, sealhulgas "kose" puhul.

Selle tulemusel saame meetodi, mis on potentsiaalselt väga kohandatav väga muutuvate projektinõuetega, kuid mis ei ole samal ajal vaba paljudest tõsistest puudustest. Viimane asjaolu ei võimalda seda meetodit soovitada kasutada kõrget või vähemalt piisavat töökindlust nõudvate projektide puhul.

ComputerPress 2"2002

Infosüsteemi juurutamise põhifaasid

Etapp “IS-i juurutamisprojekti ettevalmistamise eeltöö”. Ettevõtte projektieelse uuringu käigus kogutakse üksikasjalikku teavet organisatsiooni struktuurse struktuuri, funktsionaalsete suhete, juhtimissüsteemi, peamiste äriprotsesside, ettevõttesiseste voogude kohta (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Voolu), mis on vajalik sobivate mudelite ehitamiseks ja objektide valimiseks automatiseerimiseks. Hinnatakse ajastust, ressursse, tööde liike ja mahtu, tarkvara, riistvara ja telekommunikatsiooni ulatust ja maksumust, personali koolituse maksumust jms.

Etapp "Projekti ettevalmistamine". Pärast esimese etapi lõppu viiakse läbi esialgne planeerimine ja projekti käivitamise protseduuride kujundamine:

• projekti- ja ekspertrühmade moodustamine;
• volituste ja vastutuse jaotus;
• rakendusprotsessi organisatsiooniliste ja tehniliste nõuete määramine;
• kliendi spetsifikatsioonide ja ootuste selgitamine;
• kliendiettevõtte spetsialistidest koosneva juurutusgrupi koolitus.

Etapp “Projekti kontseptuaalne väljatöötamine”. Selles etapis:

• koostatakse ja kinnitatakse ideeprojekt;
• saavutatakse kohustuslik üheselt mõistetav arusaam kõigi projektis osalejate kavatsustest seoses rakendatava IS-iga;
• selgitatakse ja täpsustatakse projekti eesmärke ja eesmärke;
• määratakse süsteemi prototüübi mõõtmed;

· lepitakse kokku laiendatud tööplaan, proovioperatsiooni etappide järjestus ja tingimused, planeerimine, finants- ja aruandlusnäitajad;

Veelgi enam, kõik need toimingud peavad olema dokumenteeritud, kokku lepitud ja kõigi huvitatud ja vastutavate osapoolte poolt heaks kiidetud.

Etapp "Projekti rakendamine". Põhilise juurutustöö käigus luuakse, paigaldatakse ja konfigureeritakse süsteemikeskkond, määratakse süsteemi administreerimise protseduurid ning paigaldatakse põhilised riist- ja tarkvarasüsteemid ning rakendused. Süsteem konfigureerib ettevõtte organisatsioonilised, personali- ja organisatsioonilis-funktsionaalsed struktuurid, kasutades selliseid organisatsiooni üksusi nagu filiaal, osakond, osakond, töörühm jne.

Riis. 2.17. Rakendusprojekti hoidla näidissisu

Teostatakse võrgu- ja telekommunikatsioonitööriistade paigaldamine, seadistamine ja seadistamine, andmete edastamine varasematest lokaalsetest süsteemidest ning liideste moodustamine pärand- ja välissüsteemidega. Samal ajal paigutatakse kõik loodud mudelid, plaanid, töötavad tarkvaratooted ja dokumentatsioon juurutusprojekti lõpp-hoidlasse (joonis 2.17). Selle hoidla oluliseks osaks on projekti raames genereeritav dokumentatsioonisüsteem (joonis 2.18).

Süsteemi mitme kasutaja režiimis töötamise süstemaatilised turvaprobleemid töötatakse välja. Luuakse rakendused, mallid, aruanded, kliendi juurdepääsuvormid ja jagatakse kasutajaõigusi. Kõiki süsteeme testitakse "lahingurežiimis" kõigi huvitatud osapoolte osavõtul.

Riis. 2.18. IS juurutamisprotsessi dokumentatsiooni ligikaudne koosseis

Pärast rakendusfaasi lõppu loetakse rakendusprojekt lõpetatuks. Infosüsteem on kasutusele võetud.

Testi küsimused ja ülesanded

1. Mis on "avatud infosüsteem"?
2. Loetlege avatud süsteemide peamised omadused.
3. Kirjeldage ettevõtte tegevuse juhtimise kaasaegse protsessikäsitluse olemust ja selle kasutamist infosüsteemide arendamisel.
4. Mida hõlmab mõiste "äriprotsesside ümberkujundamine"?
5. Milliseid mudeleid ja kuidas neid infosüsteemide projekteerimisel kasutatakse?
6. Milliseid tarkvaravahendeid kasutatakse protsesside modelleerimiseks infosüsteemide arendamisel?
7. Millistele andmetele ja teabele tuginedes töötatakse välja olekumudeleid NAGU ON ja NAGU ON?
8. Kes ettevõttes tegeleb IP arendamise, juurutamise ja arendamisega? Kes on seotud IP arenduse tehniliste kirjelduste koostamisega?
9. Nimeta infotehnoloogia projekteerimise põhietapid.
10. Loetlege infosüsteemi elutsükli etapid.
11. Millises IS arendamise ja juurutamise etapis koolitatakse ettevõtte personali?
12. Loetlege IS-i rakendamise peamised etapid.

Peatükk 3. Arvuti infotehnoloogia tarkvara

3.1. Arvuti infotehnoloogia tarkvara üldised omadused

Arvutite infotehnoloogiate puhul toimivad tarkvaravahendid (tarkvara) tehnilise kompleksi (arvutisüsteemide) juhtimise vahenditena.

Tarkvara arendamise ja kasutamise küsimused üldiselt on üsna hästi välja töötatud ning teadus- ja õppekirjanduses laialdaselt käsitletud. Kuid mõned täpsustused on vajalikud.

Seega hõlmab mõiste “tarkvara” sisu üldmääratlus andmetöötlussüsteemi programmide kogumit ja nende programmide tööks vajalikke programmidokumente. Seda tõlgendust saab üldiselt kasutada, eriti kui tegemist on tarkvarasüsteemide kui selliste tegeliku arendamise ja toimimise probleemidega. Kuid kasutajate seisukohast tuleks asjakohaste tehnoloogiate raames operatiivdokumendid nende tarkvarast eraldada, kuna vastavalt infotehnoloogia tööriistade ja meetodite struktuurile on need seotud organisatsioonilise ja metoodilise toega.

Lisaks on tarkvara ülesehitust kirjeldatud erinevalt õppe- ja teatmekirjanduses. Selliseid mõisteid nagu “üldtarkvara”, “süsteemitarkvara”, “baastarkvara”, “rakendustarkvara”, “spetsiaalne tarkvara” kasutatakse erinevates kombinatsioonides. Samal ajal kattub nende mõistete sisu sageli, mis muudab tarkvara enda selge struktureerimise võimatuks. Järgmistes osades antakse nende mõistete sisuline kirjeldus, kuid nüüd on vaja sõnastada siin omaks võetud kontoritehnoloogia tarkvara struktureerimine. See põhineb selgelt määratletud ja mittekattuvatel funktsioonidel, mida täidavad vastavad programmid, tagades samal ajal kogu tarkvarakoostise vajaliku täielikkuse.

Tarkvara sisaldab (joonis 3.1):

Süsteemitarkvara;

Tarkvaraarendustööriistad;

Rakendustarkvara.

Joon.3 .1 . Infotehnoloogia tarkvara struktuur

Süsteemi tarkvara on omavahel ühendatud programmide kogum, mis tagab arvutitehnoloogia kui sellise toimimise, ilma programmide ja kasutajaülesannete realiseerimiseks toiminguid tegemata.

Tarkvaraarendustööriistad sisaldab erinevaid programmeerimissüsteeme, mille abil saab välja töötada teatud funktsionaalseid programme ja kohandada neid konkreetsetele rakendustingimustele konkreetsete probleemide lahendamiseks.

Rakendustarkvara on tarkvarasüsteemide komplekt, mis pakub lahendusi konkreetsetele kasutajaprobleemidele.

Edaspidi ei arvestata programmiarenduse tööriistatoega, kuna tarkvaratoodete loomise küsimused moodustavad spetsiifilise valdkonna, mis ei kuulu sekretäriteenuste hulka ja reeglina toimub programmeerimistöö ise. välja mitte kontorites, vaid spetsialiseeritud ettevõtetes ja organisatsioonides, aga ka individuaalselt.

3.2. Arvuti infotehnoloogia tarkvara elutsükkel

Infotehnoloogia tarkvara on üldiselt elutsükli kontseptsiooni raames suhteliselt sõltumatute põhimõtete ja töömustriga kompleksne süsteem.

Tarkvarasüsteemi elutsükli all mõistetakse tavaliselt korduvat ja struktuurilt ühtlast intervalli kogu selle olemasolu vältel, alustades süsteemi esialgse kontseptsiooni väljatöötamisest ja lõpetades süsteemi vananemisega.

Elutsüklit esitatakse traditsiooniliselt mitme järjestikuse etapina (või etapina, faasina). Praegu ei ole üldiselt aktsepteeritud tarkvarasüsteemi elutsükli jaotust etappideks. Mõnikord tuuakse lava esile eraldi punktina, mõnikord lisatakse see suurema lava lahutamatu osana. Ühes või teises etapis tehtavad toimingud võivad erineda. Nende etappide nimetustes pole ühtsust.

Infotehnoloogia korralduse seisukohalt on tarkvara elutsükkel esitatud järgmiselt:

· teatud tüüpi tarkvara vajaduse kindlaksmääramine kontoritehnika konkreetse funktsiooni rakendamiseks;

· konkreetse tarkvaratoote valik konkreetse kontoritehnoloogia juurutamiseks;

· tööstusliku tarkvaratoote soetamine, selle kaasajastamine või unikaalse tarkvaratoote arendamine;

· tarkvaratoote paigaldamine olemasolevale kontoriarvutisüsteemile;

· tarkvaratoote toimimine;

· tarkvaratoote efektiivsuse hindamine;

· tarkvaratoote moderniseerimine;

· tarkvaratoote lahtivõtmine.

Teatud tüüpi tarkvara vajaduse kindlaksmääramine tuleks läbi viia organisatsioonis vastavate tööde teostamise analüüsi põhjal, mille osas on juba tehtud põhimõtteline otsus arvutitehnoloogia kasutamise kohta.

Konkreetse tarkvaratoote valik peaks põhinema järgmiste tegurite ühisel kaalumisel:

· konkreetse infotehnoloogia funktsioone realiseerivate tööstustarkvaratoodete olemasolu;

· tarkvara- ja riistvaraorganisatsioonide olemasolu, mis viivad läbi konkreetse infotehnoloogia funktsioone rakendava tarkvara professionaalset arendamist;

3.3. Andmebaasihaldussüsteemide olemus ja põhimõisted

Peaaegu igas inimtegevuse valdkonnas on ühel või teisel määral vaja koguda, salvestada ja kasutada erinevaid andmeid. Sel juhul kasutatakse nendega töötamiseks erinevaid meetodeid ja tehnoloogiaid: näiliselt ebasüstemaatilised (kuid omanikule arusaadavad) kanded isiklikesse märkmikesse, teabe korrapärane salvestamine ajakirjadesse, süstematiseeritud kartoteekide pidamine, dokumentide töötlemine organiseeritud kontorikompleksis jne. .

Kõigi mainitud meetodite ja tööriistade abil saame tuvastada ühised tunnused, mis iseloomustavad andmetega töötamist:

· kogutud, salvestatud ja töödeldud andmed on seotud neid kasutavatele inimestele iseloomuliku konkreetse ja piiratud tegevusvaldkonnaga, nn. ainevaldkond,

· andmed ise on jaotatud konkreetseteks komponentideks, mis on omavahel mitmel moel seotud, st need struktureeritud Ja tellitud;

On teatud meetodid otsing Ja ekstraktid (proovid) vajalik teave ja selle esindus.

Nimetatakse konkreetse ainevaldkonnaga seotud struktureeritud ja järjestatud andmete kogum andmebaasi (DB) ning DB-s teabe kogumise, registreerimise, salvestamise, korrastamise, otsimise, hankimise ja esitamise meetodite ja vahendite süsteemi nimetatakse andmebaasihaldussüsteem (DBMS).

Kui andmebaasi on salvestatud märkimisväärses koguses teavet või kui see on tegevuse jaoks olulise tähtsusega, tekib andmetöötluse usaldusväärsuse ja kiiruse probleem. Seda probleemi saab suures osas lahendada arvutitehnoloogia abil. Vastavad DBMS-id on üsna laialt levinud ja olulise osa neist moodustavad süsteemid, mis põhinevad suhteline lähenemine.

Selle lähenemise raames kirjeldatakse aineala moodustavaid objekte atribuutide (omaduste) kogumina, mis on omavahel teatud suhetes (seostes) (sellest ka nimi suhteline: inglise keelest suhe - suhtumine). Selle populatsiooni spetsiifiline esitusviis on sageli tabeli kujul.

Vaatame näidet. Teatud projekteerimisorganisatsiooni töötajate andmed hõlmavad järgmist:

· töötaja personalinumber;

· perekonnanimi, eesnimi ja isanimi;

sünnikuupäev;

· Kodu aadress;

· kodutelefon;

töö alustamise kuupäev;

· töökoht;

· ametlik telefon;

· töö nimetus;

· lisatasu tööstaaži eest;

· projekt, milles töötaja osaleb;

· lisatasu projektis osalemise eest.

Neid andmeid saab esitada tabeli kujul, kus igal andmetüübil on oma veerg ja igal konkreetsel töötajal on rida).

Selle tabeli (seos) iga rida kutsutakse salvestus, ja selle üksikelement, mis vastab ühele või teisele veerule, on valdkonnas.

Tabel on vaid väike fragment andmebaasist, kuid selle omadused on väga soovituslikud.

Esiteks on mõned väljad üsna keerulised ja sisaldavad andmeid, mida saab (ja tuleks) jagada väiksemateks komponentideks (need on väljad, mis sisaldavad perekonnanime, eesnime ja isanime, kuupäevi, aadressi, töökohta).

Teiseks, üksikute väljade puhul dubleeritakse erinevates kirjetes olevad andmed, mis ei ole hoiukulude seisukohalt põhjendatud (info saastekvootide kohta).

Seega tuleks teine ​​väli jagada kolmeks komponendiks, mis sisaldavad eraldi töötaja perekonnanime, eesnime ja isanime; kolmas ja kuues väli koos kuupäevadega tuleb samuti jagada kolmeks - kuupäeva, kuu ja aastaga; koduaadressi väljal peate valima esimese komponendi, mis näitab piirkonda (Moskva või Moskva piirkond); ja jagada töökohta tähistav väli kaheks - osakonna number ja ruumi number.

Ebavajaliku teabe salvestamise tabelist kõrvaldamiseks on vaja eemaldada väljad, mis on seotud muude objektide kui personali omadustega ja luua nende jaoks oma seosed: näiteks tabelid “Osakond”, “Projekt” ja “Saatused”. .

Nimetatakse kirjeldatud toiminguid andmete esitamiseks andmebaasi loomise teoorias ja praktikas normaliseerimine.

Igas seoses (tabelis) peab üks väljadest mängima rolli esmane võti, konkreetse kirje kordumatu identifitseerimine, st iga kirje jaoks unikaalne väärtus. Seoses “Personal” on see personali number, “Osakonna” puhul – osakonna number, “Projekti” puhul – projekti nimi, “Toetuste” osas – tööstaaž.

Mõned ülejäänud suhteväljad võivad täita rolli sekundaarsed võtmed, mille väärtusi saab kasutada erinevate toimingute tegemiseks: andmete otsimiseks ja toomiseks.

Ülalpool tabelites toodud seosed on omavahel ühendatud eraldi väljade kaudu: seosed “Personal” ja “Osakond” - läbi “Osakonna number” välja (vastavalt teisene ja primaarvõti); suhted "Personal" ja "Projekt" - välja "Projekti nimi" kaudu (vastavalt teisene ja esmane võti). Suhete “Personal” ja “Toetused” ühendamine toimub väljade “Töötamise kuupäev” (liitvõti) ja “Töökogemus” (esmane võti) kaudu, kuid mitte otse, vaid tööaja pikkuse arvutamise protseduuri kaudu. teenus, mis põhineb töölevõtmise kuupäeva väärtusel.

Kirjeldatud näites toodud andmete struktureerimine ja järjestamine on üldiselt omane kõikidele andmebaasihaldussüsteemidele ning erineb erinevate programmide detailides.

3.4. Arvutite andmebaaside haldussüsteemid

Andmebaasi haldussüsteem on tarkvarasüsteem, mis on loodud arvutis üldise andmebaasi loomiseks, mida kasutatakse paljude probleemide lahendamiseks. Sellised süsteemid hoiavad andmebaasi ajakohasena ja pakuvad kasutajatele antud volituste raames tõhusat juurdepääsu selles sisalduvatele andmetele.

Personaalarvutiklassi arvutussüsteemide populaarseimad DBMS-id on dBASE IV, Microsoft Access, FoxPro, Paradox. Oracle ja Informix DBMS on mõeldud võimsamate süsteemide jaoks. Teatud määral on enamikul kaasaegsetel tabelitöötlusseadmetel ka andmehaldusvõimalused.

Universaalsuse astme järgi eristatakse kahte DBMS-i klassi:

· üldotstarbelised süsteemid;

· spetsiaalsed süsteemid.

Üldotstarbelised DBMS-id ei keskendu ühelegi teemavaldkonnale ega ühegi kasutajarühma teabevajadustele. Iga seda tüüpi süsteem on rakendatud tarkvaratootena, mis on võimeline töötama teatud arvutimudelil konkreetses operatsioonisüsteemis.

Spetsiaalsed DBMS-id luuakse harvadel juhtudel, kui üldotstarbelist DBMS-i on võimatu või sobimatu kasutada.

Üldotstarbelised DBMS-id on keerulised tarkvarasüsteemid, mis on loodud täitma kõiki andmebaasi infosüsteemi loomise ja toimimisega seotud funktsioone. Praegu kasutatavatel DBMS-idel on funktsioonid andmete terviklikkuse ja tugeva turvalisuse tagamiseks, võimaldades arendajatel tagada suurem andmeturve väiksema programmeerimistööga. Windowsi keskkonnas töötavad tooted eristuvad kasutajasõbralikkuse ja sisseehitatud tootlikkuse tööriistade poolest.

Vaatame mõne DBMS-i põhiomadusi – turuliidreid nii infosüsteemide arendajatele kui ka lõppkasutajatele mõeldud programmides.

TAVRITŠESKI RAHVUSÜLIKOOL

neid. IN JA. VERNADSKY

majandusteaduskond

Majandusküberneetika osakond

päevaosakond

MALÕŠEV SERGEI IVANOVICH

INFOTEHNOLOOGIATE (SÜSTEEMIDE) RAKENDAMINE ETTEVÕTTE TEGEVUSSE

Kursuse töö

2. kursuse üliõpilane, gr. 201K __________________ Malõšev S.I.

Teaduslik nõunik,

Dotsent, Ph.D. __________________ Krulikovski A.P.

Simferopol, 2009

SISSEJUHATUS ……………………………………………………………………….3

1. PEATÜKK

INFOSÜSTEEMID JA TEHNOLOOGIAD MAJANDUSES ………………………………………………………………...6

1.1. Infosüsteemide arengulugu……………………………… 6

1.2. Infotehnoloogiate ja -süsteemide klassifikatsioon…………………… 8

1.3. Infosüsteemide tüübid organisatsioonis………………………… 16

1.4. Infotehnoloogia potentsiaalsed tarbijad………… 19

1.5. Infosüsteemide kasutamise kogemus………………………. 21

2. PEATÜKK

INFOSÜSTEEMI VALIK, RAKENDAMINE JA KASUTAMINE …………………………………………………………………...22

2.1. Infosüsteemi valiku probleem…………………………. 22

2.2. Süsteemi valiku kriteeriumid………………………………………………………………. 24

2.3. Süsteemi juurutamise meetodid……………………………………………………………….. 27

2.4. Infosüsteemi juurutamise etapid…………………………. 30

JÄRELDUS………………………………………………………………………………………………………………

ALLIKATE LOETELU………………………………………………………………………………………35

Sissejuhatus

Turusuhetele üleminek majanduses ning teaduse ja tehnika areng on märkimisväärselt kiirendanud infovaldkonna uusimate saavutuste tutvustamist ühiskonna sotsiaal-majandusliku elu kõigisse sfääridesse. Mõiste "informatiseerimine" ilmus esmakordselt kohalike mitme terminali teabe- ja arvutussüsteemide ning järjekorravõrkude loomisel.

Informatiseerimine majandusprotsesside juhtimise valdkonnas hõlmab ennekõike töötajate tootlikkuse tõstmist kulude ja toodangu suhte vähendamise kaudu, samuti juhtimistegevusega tegelevate spetsialistide kvalifikatsiooni ja ametialase kirjaoskuse tõstmist. Arenenud riikides toimub samaaegselt kaks omavahel seotud revolutsiooni: infotehnoloogias ja ettevõtluses, üksteist vastastikku abistades.

Infotehnoloogiad on eksisteerinud pikka aega, seetõttu hakkasid arvutite ja side arenedes ilmnema erinevad variatsioonid: "info- ja kommunikatsioonitehnoloogiad", "arvutite infotehnoloogiad" jne. Selles töös mõistame infotehnoloogia all. tänapäevane tähendus, see tähendab arvutite, elektroonika ja sidevahendite integreerimine.

Sellel terminil on palju definitsioone, näiteks:

Infotehnoloogia on süsteemselt organiseeritud meetodite ja vahendite kogum juhtimisprobleemide lahendamiseks teabe kogumise, registreerimise, edastamise, kogumise, otsimise, töötlemise ja kaitsmise toimingute läbiviimiseks, mis põhineb arendatud tarkvara, arvuti ja kasutatavate sidevahendite kasutamisel, nagu samuti meetodid, mille abil klientidele teavet pakutakse.

Infotehnoloogia ja juhtimise vahel on seos. Juht peab alati langetama otsuseid suure ebakindluse tingimustes: inflatsioon, valuutakursi muutused, maksu- ja töötingimuste muutused ning konkurendid ei maga. Arvutid suudavad kiiresti ja täpselt välja arvutada valikuvõimalusi ning seega anda vastuseid igasugustele seda tüüpi küsimustele. See on võib-olla üks arvuti peamisi eeliseid inimese ees.

Uut infotehnoloogiat iseloomustavad:

Kasutaja töö manipuleerimisrežiimis;

Lõpp-otsani teabe tugi kõikidel teabevoo etappidel, mis põhineb integreeritud andmebaasidel, pakkudes ühtset ühtset esitusviisi, salvestamist, otsimist, kuvamist, taastamist ja andmete kaitset;

Paberivaba dokumenditöötlusprotsess;

Interaktiivne probleemide lahendamise režiim;

Sidevahenditega ühendatud klient-server võrgutehnoloogial põhinevate dokumentide kollektiivse täitmise võimalused;

Vormide adaptiivse ümberstruktureerimise võimalused ja teabe esitamise meetodid probleemi lahendamise protsessis.

Arvutitehnoloogia asendamatus seisneb selles, et see võimaldab optimeerida ja ratsionaliseerida juhtimisfunktsiooni, kasutades uusi teabe kogumise, edastamise ja teisendamise vahendeid.

Mida võib anda infosüsteemi juurutamine?

ettevõtte üldkulude vähendamine tarneahelas (hangete puhul),

Käibe kiiruse suurendamine,

üleliigse laoseisu vähendamine miinimumini,

tootevaliku suurendamine ja keerukus,

Toote kvaliteedi parandamine,

Tellimuste õigeaegne täitmine ja klienditeeninduse üldise kvaliteedi parandamine.

Majandusobjektide haldamise meetodite reform ei hõlmanud mitte ainult juhtimistegevuse automatiseerimise protsessi korralduse ümberkorraldamist, vaid ka nende tegevuste uute rakendamise vormide levikut. Käesoleva töö eesmärgiks on uurida meetodeid uue infosüsteemi juurutamiseks ja arvestada selle kasutamise tulemusi.

1.1. Infosüsteemide arengu ajalugu

Infosüsteemide arengulugu ja nende kasutamise eesmärgid erinevatel perioodidel on toodud tabelis 1.

Tabel 1. Muutuv lähenemine infosüsteemide kasutamisele

Ajaperiood	Teabe kasutamise kontseptsioon	Infosüsteemide tüüp	Kasutusotstarve
1980 -???? gg.	Arveldusdokumentide pabervoog Elementaarne abi aruannete koostamisel Müügi (müügi) juhtimiskontroll Info on strateegiline ressurss, mis annab konkurentsieelise	Infosüsteemid arveldusdokumentide töötlemiseks elektromehaanilistel arvestusmasinatel Juhtimisinfosüsteemid tootmisinfo jaoks Otsustamist toetavad süsteemid Kõrgemale juhtkonnale mõeldud süsteemid Strateegilised infosüsteemid. Automatiseeritud kontorid	Dokumentide menetlemise kiiruse suurendamine Arvete menetlemise ja palgaarvestuse protseduuride lihtsustamine Aruandlusprotsessi kiirendamine Kõige ratsionaalsema lahenduse väljatöötamine Ettevõtte püsimajäämine ja õitseng

Esimesed infosüsteemid ilmusid 50ndatel. Nendel aastatel olid need mõeldud arvete ja palgaarvestuse töötlemiseks ning rakendati elektromehaanilistel arvestusmasinatel. See tõi kaasa kulude ja paberdokumentide ettevalmistamise aja vähenemise.

60ndad neid iseloomustab suhtumise muutumine infosüsteemidesse. Nendelt saadud teavet hakati kasutama paljude parameetrite perioodiliseks aruandluseks. Selle saavutamiseks vajasid organisatsioonid mitmeotstarbelisi arvutiseadmeid, mis on suutelised täitma paljusid funktsioone, mitte ainult töötlema arveid ja arvutama palka, nagu varem.

70ndatel - 80ndate alguses. Infosüsteeme hakatakse laialdaselt kasutama juhtimiskontrolli, otsustusprotsessi toetava ja kiirendava vahendina.

80ndate lõpuks. Infosüsteemide kasutamise kontseptsioon on taas muutumas. Need muutuvad strateegiliseks teabeallikaks ja neid kasutatakse mis tahes organisatsiooni kõigil tasanditel. Selle perioodi infosüsteemid, mis annavad õigel ajal vajalikku teavet, aitavad organisatsioonil saavutada edu oma tegevuses, luua uusi kaupu ja teenuseid, leida uusi turge, kindlustada väärilisi partnereid, korraldada madala hinnaga toodete tootmist ja palju muud.

Infotehnoloogiaid saab praegu klassifitseerida mitmete tunnuste järgi, eelkõige: infosüsteemis rakendamise meetod, juhtimisülesannete katvuse määr, rakendatavate tehnoloogiliste toimingute klassid, kasutajaliidese tüüp, kasutusvõimalused. arvutivõrk ja teenindatav teemavaldkond.

Tabel 2. Infotehnoloogiate klassifikatsioon.

INFOTEHNOLOOGIA	Vastavalt rakendusmeetodile IS-is	Traditsiooniline
		Uued infotehnoloogiad
	Vastavalt juhtimisülesannete hõlmatuse astmele	Elektrooniline andmetöötlus
		Juhtimisfunktsioonide automatiseerimine
		Otsuste toetamine
		Elektrooniline kontor
		Ekspertide tugi
	Rakendatavate tehnoloogiliste toimingute klasside järgi	Töö tekstiredaktoriga
		Töö lauaprotsessoriga
		DBMS-iga töötamine
		Töö graafiliste objektidega
		Multimeediumisüsteemid
		Hüperteksti süsteemid
	Kasutajaliidese tüübi järgi	Partii
		Vestlusvõimeline
	Vastavalt võrgu ehitamise meetodile	Kohalik
		Mitmetasandiline
		Levitatud
	Teenindusvaldkonna järgi	Raamatupidamine
		Pangandustegevus
		Maksutegevus
		Kindlustustegevus

Vaatleme infosüsteemide ja infotehnoloogiate vahelisi seoseid.

Majandusinfosüsteem on majandusobjekti, meetodite, tööriistade, infotöötlusprotsessi ja juhtimisotsuste väljatöötamisse kaasatud spetsialistide otsese ja tagasisidega infosuhtluse sisemiste ja väliste voogude kogum.

Automatiseeritud infosüsteem on teabe, majanduslike ja matemaatiliste meetodite ja mudelite, tehniliste, tarkvaraliste, tehnoloogiliste vahendite ja spetsialistide kogum, mis on mõeldud teabe töötlemiseks ja juhtimisotsuste tegemiseks.

Seega võib infosüsteemi tehnilises mõttes defineerida kui omavahel seotud komponentide kogumit, mis koguvad, töötlevad, salvestavad ja levitavad informatsiooni, et toetada otsuste tegemist ja juhtimist organisatsioonis. Lisaks otsuste tegemise, koordineerimise ja kontrolli toetamisele võivad infosüsteemid aidata juhtidel analüüsida probleeme, muuta keerulised objektid nähtavaks ja luua uusi tooteid.

Infosüsteemid sisaldavad teavet oluliste inimeste, kohtade ja objektide kohta organisatsioonis või keskkonnas. Teave on andmed, mis on teisendatud kasutajatele tähenduslikuks ja kasulikuks vormiks. Andmed on seevastu töötlemata faktide vood, mis esindavad tulemusi, mis on leitud organisatsioonidest või füüsilisest keskkonnast enne, kui need on korraldatud ja teisendatud kujul, mida kasutajad saavad mõista ja kasutada.

Vastuvõtuallikate alusel saab teabe jagada väliseks ja sisemiseks. Välisinfo koosneb kõrgemate asutuste käskkirjadest, erinevatest kesk- ja kohalike omavalitsuste materjalidest, teistelt organisatsioonidelt ja seotud ettevõtetelt saadud dokumentidest. Siseteave kajastab andmeid ettevõtte tootmise edenemise, plaani elluviimise, töökodade töö, teenindusalade ja toodangu turustamise kohta.

Kõik ettevõtte juhtimiseks vajalikud teabe liigid moodustavad infosüsteemi. Juhtimissüsteem ja infosüsteem igal juhtimistasandil moodustavad ühtsuse. Juhtimine ilma teabeta on võimatu.

Infosüsteemi kolm protsessi toodavad teavet, mida organisatsioonid vajavad otsuste tegemiseks, probleemide haldamiseks, analüüsimiseks ja uute toodete või teenuste loomiseks – sisend, töötlemine ja väljund.

Teabe sisestamine välistest või sisemistest allikatest;

Sisendinfo töötlemine ja mugaval kujul esitamine;

Teabe väljastamine tarbijatele esitamiseks või teise süsteemi ülekandmiseks;

Tagasiside on teave, mida töötlevad antud organisatsiooni inimesed sisendteabe parandamiseks.

Riis. 1. Protsessid infosüsteemis

Sisestusprotsessi käigus salvestatakse või kogutakse organisatsioonisiseselt või väliskeskkonnast kontrollimata teavet. Töötlemine muudab selle tooraine tähendusrikkamaks vormiks. Väljundi etapis edastatakse töödeldud andmed personalile või protsessidele, kus neid kasutatakse. Infosüsteemid vajavad ka tagasisidet, milleks on tagastatud töödeldud andmed, mis on vajalikud selleks, et kohandada organisatsiooni elemente, et aidata töödeldavaid andmeid hinnata või parandada.

Infosüsteemi määratlevad järgmised omadused:

Igasugust infosüsteemi saab analüüsida, ehitada ja hallata hoonesüsteemide üldiste põhimõtete alusel;

Infosüsteem on dünaamiline ja arenev;

Infosüsteemi ülesehitamisel on vaja kasutada süsteemset lähenemist;

Infosüsteemi väljund on informatsioon, mille alusel tehakse otsuseid;

Infosüsteemi tuleks tajuda kui inimene-arvuti infotöötlussüsteemi.

On olemas ametlikud ja mitteametlikud organisatsioonilised arvutiteabesüsteemid. Ametlikud süsteemid tuginevad aktsepteeritud ja organiseeritud andmetele ja protseduuridele nende andmete kogumiseks, säilitamiseks, tootmiseks, levitamiseks ja kasutamiseks.

Mitteametlikud infosüsteemid (näiteks kuulujutud) põhinevad kaudsetel kokkulepetel ja kirjutamata käitumisreeglitel. Puuduvad reeglid selle kohta, mis teave on või kuidas seda kogutakse ja töödeldakse. Sellised süsteemid on organisatsiooni eluks vajalikud. Neil on infotehnoloogiaga väga kauge suhe.

Kuigi arvutite infosüsteemid kasutavad arvutitehnoloogiat kontrollimata teabe töötlemiseks tähenduslikuks teabeks, on ühelt poolt arvutil ja arvutiprogrammil ning teiselt poolt infosüsteemil selge erinevus. Elektroonilised arvutid ja nende jaoks mõeldud programmid on kaasaegsete infosüsteemide tehniline alus, tööriistad ja materjalid. Arvutid pakuvad seadmeid teabe salvestamiseks ja tootmiseks. Arvutiprogrammid ehk tarkvara on hooldusjuhendite komplektid, mis kontrollivad arvutite tööd. Kuid arvutid on vaid osa infosüsteemist.

Ärilisest vaatenurgast kujutab infosüsteem infotehnoloogial põhinevaid organisatsioonilisi ja juhtimisotsuseid vastuseks keskkonnast tulenevatele väljakutsetele. Infosüsteemide mõistmine ei tähenda arvutioskust, juhil peab olema laiem arusaam infosüsteemide korraldusest, juhtimisest ja tehnoloogiast ning nende oskusest pakkuda lahendusi ärikeskkonna probleemidele.

Infosüsteemide klassifitseerimisel on mugav eristada CRM-i (kliendisuhted), ERP-i (ettevõtte juhtimine) ja MPC-süsteeme (finantstulemusel põhinev juhtimine).

Koduturul on sellise klassifikatsiooni piirid väga hägused, näiteks tuntud finantssüsteem 1C positsioneeritakse ERP-na, samas oleks vale väita, et 1C on konkurent sellisele ERP-süsteemile nagu Navision. Axaptra.

Esimesed süsteemid, mis töötati välja ettevõtte juhtimise probleemide lahendamiseks, hõlmasid peamiselt lao- või materjaliarvestuse valdkonda (IC – Inventory Control). Nende välimus on tingitud asjaolust, et materjalide (tooraine, valmistoodang, kaubad) arvestus on ühelt poolt ettevõtte juhi jaoks igavene erinevate probleemide allikas, teisalt aga (suhteliselt suures ettevõttes) kõige töömahukamad alad, mis nõuavad pidevat tähelepanu . Sellise süsteemi peamine “tegevus” on materjalide arvestus.

Materjaliarvestuse täiustamise järgmist etappi tähistasid tootmis- või materjaliressursside (olenevalt organisatsiooni tegevuse suunast) planeerimise süsteemid. Need süsteemid, mis sisalduvad standardis või pigem kahes standardis (MRP - Material Requirements Planning ja MRP II - Manufacturing Requirements Planning), on läänes väga levinud ja neid on juba pikka aega edukalt kasutatud ettevõtetes, peamiselt töötlevas tööstuses. Põhiprintsiibid, mis olid MRP standardsüsteemide aluseks, hõlmavad järgmist

Tootmistegevuse kirjeldus omavahel seotud tellimuste voona;

Ressursipiirangutega arvestamine korralduste täitmisel;

Tootmistsüklite ja varude minimeerimine;

Tarne- ja tootmistellimuste moodustamine müügitellimuste ja tootmisgraafikute alusel.

Muidugi on ka teisi MRP funktsioone: protsessitsükli planeerimine, seadmete koormuse planeerimine jne. Tuleb märkida, et MRP standardsüsteemid ei lahenda mitte niivõrd raamatupidamise, kuivõrd ettevõtte materiaalsete ressursside haldamise probleemi.

Hetkel populaarseimad uut tüüpi infosüsteemid on ERP – Enterprise Resource Planning süsteemid. ERP-süsteemid ei hõlma oma funktsionaalsuses mitte ainult laoarvestust ja materjalihaldust, mida ülalkirjeldatud süsteemid täies mahus pakuvad, vaid lisavad sellele kõik muud ettevõtte ressursid, eelkõige rahalised. See tähendab, et ERP-süsteemid peavad hõlmama kõiki ettevõtte valdkondi, mis on otseselt seotud selle tegevusega. Esiteks puudutab see tootmisettevõtteid. Selle standardi süsteemid toetavad põhiliste finants- ja juhtimisfunktsioonide rakendamist. Näiteks Baani süsteemides on see:

rahandus ja raamatupidamine,

Tootmine,

Müük (sh laoarvestus, kaubandus ja turundus),

transport,

Seadmete hooldus ja hooldus,

Projekti juht,

Ja ka ühtne halduspaneel - juhi infosüsteemi moodul, millelt juht näeb kõiki peamisi osakondi ja tootmisnäitajaid.

ERP-süsteemide põhiülesanne on jälgida ettevõtte hetkeseisu ja teavitada juhte kõigist ohtlikest muudatustest tootmistegevuses.

Infosüsteemil, nagu igal teisel tööriistal, peavad olema oma omadused ja nõuded, mille järgi saab määrata selle funktsionaalsust ja efektiivsust. Loomulikult on iga konkreetse ettevõtte puhul nõuded infosüsteemile erinevad, kuna arvestada tuleb iga organisatsiooni eripäradega.

Sellele vaatamata on vaja rõhutada mitmeid süsteemi põhinõudeid, mis on ühised kõigile "tarbijatele":

1. Infosüsteemi lokaliseerimine. Tulenevalt asjaolust, et suurimad infosüsteemide arendajad on välisfirmad, tuleb süsteem kohandada kasutamiseks kodumaistele ettevõtetele. Ja siin peame silmas lokaliseerimist, nii funktsionaalset (võttes arvesse Ukraina seadusandluse ja maksesüsteemide iseärasusi) kui ka keelelist (ukraina keeles abisüsteem ja dokumentatsioon).

2. Süsteem peab tagama usaldusväärse infokaitse, mis eeldab paroolipõhist juurdepääsukontrolli, mitmetasandilist andmekaitsesüsteemi jne.

3. Kui süsteem on juurutatud keerulise organisatsioonilise ülesehitusega suurettevõttes, on vajalik juurutada kaugjuurdepääs, et infot saaks kasutada kõik organisatsiooni struktuuriüksused.

4. Väliste ja sisemiste tegurite mõju tõttu (muutused ärisuunas, muudatused seadusandluses jne) peab süsteem olema adaptiivne. Ukraina puhul tuleks seda süsteemi kvaliteeti tõsisemalt käsitleda, kuna meie riigis toimuvad muudatused seadusandluses ja raamatupidamisreeglites mitu korda sagedamini kui stabiilse majandusega riikides.

5. Teavet on vaja koondada ettevõtte tasandil (kombineerides teavet filiaalidest, tütarettevõtetest jne), üksikute ülesannete ja ajaperioodide tasandil.

Need nõuded on peamised, kuid kaugeltki ainsad kriteeriumid ettevõtte ettevõtte infosüsteemi valimisel.

Kuna organisatsioonis on erinevad huvid, omadused ja tasemed, siis on olemas erinevat tüüpi infosüsteeme. Ükski süsteem ei suuda täielikult rahuldada organisatsiooni teabevajadusi. Organisatsiooni võib jagada tasanditeks: strateegiline, juhtimis-, teadmus- ja operatiivne; ning sellistesse funktsionaalsetesse valdkondadesse nagu müük ja turundus, tootmine, rahandus, raamatupidamine ja inimressursid. Süsteemid on loodud nende erinevate organisatsiooniliste huvide teenindamiseks. Erinevaid organisatsiooni tasandeid teenindavad neli peamist infosüsteemide tüüpi: operatiivtasandi süsteemid, teadmiste taseme süsteemid, juhtimistasandi süsteemid ja strateegilise tasandi süsteemid.

Tabel 3. Infosüsteemide tüübid.

Operatsioonitaseme süsteemid toetavad operatsioonide juhte, jälgides põhilisi organisatsioonilisi tegevusi, nagu müük, maksed, sissemaksete tasumine ja palgaarvestus. Süsteemi põhieesmärk sellel tasemel on vastata rutiinsetele küsimustele ja liigutada tehinguvooge läbi organisatsiooni. Seda tüüpi küsimustele vastamiseks peab teave üldiselt olema kergesti juurdepääsetav, õigeaegne ja täpne.

Teadmussüsteemid toetavad teadmustöötajaid ja andmetöötlejaid organisatsioonis. Teadmussüsteemide eesmärk on aidata integreerida uusi teadmisi ärisse ja aidata organisatsioonil hallata dokumendivoogu. Teadmussüsteemid, eriti tööjaamade ja kontorisüsteemide kujul, on tänapäeval kõige kiiremini kasvavad rakendused ettevõtluses.

Juhtimistaseme süsteemid on loodud keskastme juhtide kontrolli-, juhtimis-, otsustus- ja haldustegevuse teenindamiseks. Nad määravad kindlaks, kas objektid toimivad hästi, ja annavad perioodiliselt aru. Näiteks liikumisjuhtimissüsteem annab aru kogu varude liikumisest, müügiosakonna ja töötajate kulusid finantseeriva osakonna ühtsusest kõigis ettevõtte osades, märkides ära, kus tegelikud kulud ületavad eelarveid.

Mõned juhtimistasandi süsteemid toetavad ebatavalist otsuste tegemist. Nad kipuvad keskenduma vähem struktureeritud lahendustele, mille teabenõuded ei ole alati selged.

Strateegilise taseme süsteemid on abivahend tippjuhtidele, kes koostavad strateegilisi uuringuid ja pikaajalisi trende ettevõttes ja ärikeskkonnas. Nende peamine eesmärk on sobitada töötingimuste muutused olemasolevate organisatsiooniliste võimalustega.

Infosüsteeme saab eristada ka funktsionaalselt. Põhilisi organisatsioonilisi funktsioone, nagu müük ja turundus, tootmine, rahandus, raamatupidamine ja inimressursid, toetavad patenteeritud infosüsteemid. Suurtes organisatsioonides on ka nende põhifunktsioonide alamfunktsioonidel oma infosüsteemid. Näiteks tootmisfunktsioonil võivad olla varude juhtimise, protsesside juhtimise, tehase hoolduse, arvutipõhise inseneri ja materjalinõuete planeerimise süsteemid.

Tüüpilisel organisatsioonil on süsteemid erinevatel tasanditel: operatiiv-, juhtimis-, teadmiste- ja strateegilised süsteemid iga funktsionaalse valdkonna jaoks. Näiteks on ärifunktsioonil äritasandil kommertssüsteem igapäevaste äriandmete salvestamiseks ja tellimuste töötlemiseks. Teadmiste taseme süsteem loob ettevõtte toodete demonstreerimiseks sobivad väljapanekud. Juhtimistaseme süsteemid jälgivad igakuiseid müügiandmeid kõigi kommertsterritooriumide kohta ja annavad aru territooriumidest, kus müük ületab oodatud taset või langeb alla eeldatava taseme. Prognoosisüsteem ennustab ärisuundumusi viie aasta jooksul – teenides strateegilist taset.

1.4 . Potentsiaalsed tarbijad infotehnoloogiad

Infotehnoloogia kasutamise seisukohalt võib peaaegu kogu turul olevad ettevõtted jagada nelja kategooriasse, milles:

· väljatöötamise käigus võeti kasutusele erinevad, omavahel mitteseotud süsteemid ettevõtte raamatupidamiseks ja juhtimiseks teatud tegevusaladel nagu müük, ost, ladu, raamatupidamine, personal jne;

· kasutusele võeti integreeritud infosüsteem, mis on välja töötatud “tellimusel” ja mis sisaldab komponente loetletud võimalike moodulite loetelust, kuid ei vasta tänapäevasele tasemele ja pidevalt uute standardite nõuetele;

· infotehnoloogiaid (v.a raamatupidamine) protsesside ja ressursside juhtimisel praktiliselt ei kasutata;

· on püütud juurutada tööstuslikku süsteemi, mille omadused vastavad ühe aktsepteeritud standardi (MRP, MRPII, ERP jne) nõuetele, kuid juurutamise tulemus on mitterahuldav.

On veel kaks kategooriat, kuid need ettevõtted ei ole suure tõenäosusega enam uute lahenduste potentsiaalsed tarbijad. Mõned neist on oma valiku juba teinud ja juurutavad, teised on edukalt juurutanud mõnda tuntud ERP-süsteemi (kuid Ukrainas selliseid ettevõtteid praktiliselt pole).

Vaatamata küllaltki kõrgele pakkumise tasemele ja potentsiaalselt suurele nõudlusele otsustavad sellise muudatuse ette võtta vaid vähesed tippjuhid.

Juhid, kellel juba mõni infosüsteem töötab, seisavad dilemma ees: kas kulutada märkimisväärne summa “integreeritud lahendusele”, mille mõju pole kaugeltki ilmne, ja samal ajal visata minema “vanad head” programmid, mis ei tööta. kaasaegsele tasemele vastavad teostused, kuid ajaproovitud ja “töötavad”; või jätta kõik nii nagu on ja unustada kaasaegsed ERP-i, e-äri kontseptsioonid ja muud saavutused juhtimisvaldkonnas ning kaotada vastavalt teatud konkurentsieelised.

Ettevõtete juhid, kus parimal juhul on veel ainult raamatupidamisosakonna töö automatiseeritud, tunnevad IT-lahenduste juurutamise tehnoloogiat ja vajaminevate ressursside mahtu üldiselt halvasti.

Lõpetuseks, juhid, kes on juba kogenud mõne tuntud süsteemi ebaõnnestunud juurutamist, omavad selles asjas eriarvamust ning väga raske on leida argumente, mis paneks uskuma eduka muutuse võimalikkusesse ja uuesti proovima.

1 .5. Infosüsteemide kasutamise kogemus

Paljud USA ja Euroopa suurettevõtted läksid mitu aastat tagasi üle ERP standardsete infosüsteemide kasutamisele. Aasia riikide kohta seda veel öelda ei saa. Enamik Aasia ettevõtete finantsjuhte pole sellistest süsteemidest peaaegu midagi kuulnud, rääkimata nende rakendamisest.

Kuigi on ettevõtteid, kes on otsustanud ERP-süsteemidele üle minna.

Infosüsteemide arendajad, eelkõige SAP, Baan, Oracle, PeopleSoft ja J.D. Edwards, reklaamivad oma tooteid üsna agressiivselt, mis jätab valdkonna vähem tundvatele inimestele mulje, et need programmid suudavad lahendada kõik nende ettevõtete probleemid.

Statistika näitab, et enamik infosüsteemi juurutamise katseid lõppes ebaõnnestumise, suurte kahjude või pankrotiga.

Näiteks FoxMeyeri juhtkond väidab, et ERP-süsteemi ekslik rakendamine viis selle pankrotti. Ettevõte süüdistab selles süsteemi loojaid ja konsultante. Sama saatus tabas Dell Computerit, Dow Chemicali ja Kellogg’si.

Kuid on ka näiteid ERP-süsteemide edukast kasutamisest. Näiteks telekommunikatsioonifirma Aliant väidab, et ERP-süsteemi juurutamise projekt oli väga edukas. Selle projekti eeldatav investeeringutasuvus oli 33%.

Vaatamata paljudele ebaõnnestunud katsetele infosüsteeme juurutada, mõtlevad paljud ettevõtted üle maailma tõsiselt oma tegevust parandava süsteemi loomisele. Tõenäoliselt on see täiesti õigustatud, kuna mõistliku professionaalse lähenemisega infosüsteemi rakendamisele saate luua tööriista tõhusamaks ärijuhtimiseks.

Peatükk 2. Infosüsteemi valik, juurutamine ja toimimine

2.1. Infosüsteemi valiku probleem

Infosüsteemi nõuded.

Tööstusettevõtte juhtimisinfosüsteem ei tohiks piirduda ainult äriprotsesside juhtimisega. See süsteem peaks ühendama kõik kolm ettevõttes toimuvate protsesside juhtimise taset:

· äriprotsesside juhtimine

· disaini arenduste juhtimine

· tootmisprotsessi juhtimine.

Ettevõtte juhtimise infosüsteemi ühtsus seisneb selles, et süsteemi mis tahes tasemel saadud või sisestatud andmed peavad olema kättesaadavad kõikidele selle komponentidele (ühekordse sisestuse põhimõte).

Maailma kogemus infotehnoloogia kasutamisel ütleb, et sellise ühtse ettevõtte juhtimise infosüsteemi struktuur peaks olema järgmine:

Ühtse ettevõtte juhtimise infosüsteemi selgrooks on ettevõtte äriprotsesside juhtimissüsteem – ERP (Enterprise Resources Planning) klassisüsteem. Vajalikuks elemendiks on projekteerimis- ja inseneritegevuse ning tootmise tehnoloogilise ettevalmistamise automaatikasüsteemid (CAD/CAM/CAE/PDM), mis tagavad tootmistsükli aja lühenemise ja toote kvaliteedi parandamise. Kolmas element on tootmisprotsesside juhtimissüsteemid. Vahevara tagab kõigi eelnevalt kirjeldatud lahenduste koosmõju ühtse info- ja analüütilise ettevõtte juhtimissüsteemi raames.

Probleemid valikuga.

Seistes silmitsi vajadusega juurutada ettevõttes infosüsteeme, seisab juhtkond silmitsi valikuprobleemiga. Arenda ise või osta ja kui ostad, mis siis.

Kaasaegse juhtimissüsteemi iseseisva arendamise tõenäosust objektiivselt hinnates võib julgelt väita, et see on null. Kogu lugupidamise juures meie arendajate vastu võime kindlalt väita, et isegi kui nad suudavad välja töötada ettevõtte juhtimissüsteemi, ei juhtu seda niipea. Kõige populaarsemate kaasaegsete juhtimissüsteemide väljatöötamise ajalugu on 20-25 aastat ja tuhandeid töötavaid paigaldusi. Kuid iga süsteemi paigaldamine pole ainult raha uuteks arendusteks, see on ennekõike tagasiside kliendi vajadustest.

Minu arvates peaksid suurettevõtted keskenduma lääne süsteemidele. Ja järgmine küsimus, millele tuleb vastust leida, on milline lääne süsteem valida?

Ukraina kasutaja jaoks on selliste süsteemide valik piiratud. Nõukogude järgsele turule pole sisenenud palju lääne ettevõtteid. Tegelikult on need SAP, Computer Associates, BAAN ja ISF. Väljumiskatseid tegid ORACLE, JDEdvards, SSA, JBA ja QAD. Veelgi enam, ainult SAP-i ja Computer Associatesi toodetel on tegelikud rakendused. Lisaks on erinevatele ettevõtetele mõeldud erinevad süsteemid. Mõned, nagu SAP või CA-Masterpiece, on suunatud ettevõtete turule, teised, nagu BAAN või MK Enterprise (endine MANMAN/X) tööstusettevõtete või ettevõtete turule. Ja ettevõte peab tegema õige valiku, et tõrke tagajärjel ei satuks süsteem, mis talle ei sobi.

2.2. Süsteemi valiku kriteeriumid

Funktsionaalsus.

Süsteemi funktsionaalsuse all mõistetakse selle vastavust nendele ärifunktsioonidele, mis on juba olemas või mida alles plaanitakse organisatsioonis juurutada. Näiteks kui organisatsiooni eesmärk on vähendada rahalisi kahjusid defektide vähendamise kaudu, siis peaks valitud süsteem tagama kvaliteedikontrolli protsessi automatiseerimise.

Tavaliselt selleks, et teha kindlaks, kas süsteem vastab esitatud funktsionaalsetele nõuetele, piisab selgest arusaamast ettevõtte arendamise strateegiast, ettevõtte kontekstipõhisest kirjeldusest ja ettevõtte tegevuse ametlikust kirjeldusest. Kui kõik need süsteemi valimiseks vajalikud komponendid puuduvad, kaasatakse need süsteemi valiku lähteandmete koostamise etappi. Sellise mastaabiga töö tegemiseks on vaja küllaltki palju töötajaid, kuid kuna ettevõttes pole mõtet sellist personali pidevalt ülal pidada, siis tundub kõige õigem kutsuda väliskonsultandid.

Väliste konsultantidega suhtlemise tulemusena saadud selgelt struktureeritud arusaam oma organisatsiooni äriprotsessidest aitab mitte ainult ettevõtte infosüsteemi ülesehitamisel, vaid ka kõrgemal juhtkonnal oma organisatsiooni tööd paremini ette kujutada. laenata teiste organisatsioonide kogemusi.

Kogu omamiskulu.

Omandi kogukulu on suhteliselt uus mõiste. See viitab otseste ja kaudsete kulude summale, mida süsteemi omanik kannab selle elutsükli jooksul.

On vaja selgelt määratleda iga kavandatava süsteemi elutsükkel, mis hõlmab olemasoleva süsteemi eluiga, uue projekteerimise aega, komponentide ostmise ja uue süsteemi juurutamise aega, tööaega, piirdub perioodiga, mil selle töö tulemusest tagastatakse 90% süsteemi maksumusest ning kõigi otseste ja kaudsete kulude summa.

Arenguväljavaated.

Arenguväljavaated on süsteemis sätestatud süsteemi tarnija ja standardite kogumi poolt, millele ta vastab.

Ilmselgelt avaldab arenguväljavaadetele tohutut mõju ka süsteemi tarnija stabiilsus turul. Jätkusuutlikkuse kindlaksmääramiseks on vaja selgelt teada, milline süsteemi omandivorm tarnijal on, milline osa tal turul on ja kui kaua ta on turul eksisteerinud.

Tehnilised andmed.

Tehniliste kirjelduste mõistmine on parim viis tagada, et süsteem vastab ettenähtud eesmärgile. Tehnilised omadused hõlmavad järgmist:

Süsteemi arhitektuur,

usaldusväärsus,

skaleeritavus,

Taastumisvõime

varundusvõimaluste olemasolu,

Kaitsevahendid tehniliste rünnakute eest,

Võimalus integreerida teiste süsteemidega.

Riskide minimeerimine.

Riski all mõistetakse tavaliselt teatud tõenäosust, et juhtimisinfosüsteemi juurutamisel jääb mõni eesmärk saavutamata. Ilmselgelt võib organisatsioon sel juhul oodata nii ühekordset rahakaotust, mis mõjutab oluliselt süsteemi elutsüklit, kui ka pikaajalist ja pidevat raha lekkimist.

Selle tõenäosuse vähendamiseks viiakse läbi igakülgne riskitegurite analüüs ja lahenduse etapiviisiline rakendamine. Igale etapile eelneb uus hinnang tegelikkusele ja otsust muudetakse teatud viisil.

Investeerimisriskide minimeerimiseks eristatakse järgmisi kuluobjekte:

· süsteemi loomise protsess

· varustus

· tarkvara

· personal

· ülesannete haldamine

Iga kuluobjekti kohta esitatakse rida omadusi, millele see peab vastama, et riske vähendada.

2.3. Süsteemi juurutamise meetodid

Ettevõte, kes plaanib arvutihaldussüsteemi juurutada, seab tavaliselt järgmised juhised: süsteem peab olema töökorras nii kiiresti kui võimalik, õigeaegselt ja eelarve piires. Mõned organisatsioonid väldivad selliste süsteemide juurutamist, kartes, et seda ei kasutata, ja kui seda kasutatakse, on see ebatõhus. Lisaks lahkuvad ettevõttest töötajad, kes omandavad süsteemi juurutamise käigus uusi oskusi ning seejärel on raske leida tehnilisi ressursse selle toimimise säilitamiseks. See ei säästa ressursse ega rakenda rakendatud süsteemi funktsionaalset eesmärki.
Need hirmud on täiesti õigustatud. Süsteemide juurutamise projektid ebaõnnestuvad isegi muidu hea juhtimisega ettevõtetes. Juhtudel, kui kõik läheb enam-vähem normaalselt, ei peeta sageli kinni kommertstegevuse alustamise tähtaegadest ja ei ole võimalik jääda eraldatud eelarve piiresse. Kuid allpool kirjeldatud meetodid võivad õige kasutamise korral aidata minimeerida juurutamise ebaõnnestumise riski. Õige planeerimise ja juhtimisega on täiesti võimalik tähtaegadest kinni pidada ja eelarve piiresse jääda. Algusest peale peate veenduma, et projekt on korralikult korraldatud.

Vajalik:

1. Saavutage usk edusse ja pühendumus nende poolt, kes mängivad projekti elluviimisel võtmerolli.

2. Tehke kindlaks, kes on täiskohaga süsteemi juurutamise projektijuht. Sellel isikul peavad olema sellise töö tegemiseks vajalikud oskused, soovitavalt süsteemide juurutamise kogemus.

3. Määratlege selgelt ja kajastage dokumentides iga projekti kallal töötava spetsialistide meeskonna liikme funktsioonid ja vastutusalad ning pädevuse ulatus.

4. Tagada, et neid ülesandeid täitvatel inimestel oleksid vajalikud oskused.

5. Koostage üksikasjalik tööplaan, jagage see etappideks, määrake ülesannete täitmise tähtajad ja pidage neist kinni.

Enne süsteemi juurutamise alustamist peate läbi mõtlema organisatsioonilise struktuuri ja äriprotsessid:

1. Veenduge, et raamatupidamiseeskirjad ja -protseduurid oleksid dokumentides fikseeritud ettenähtud vormis ning raamatupidamistöötajatele arusaadavad.

2. Kirjeldage ärimeetodeid ja toiminguid, mida nende rakendamise tulemusena tuleb teha.

3. Vajadusel muutke neid meetodeid, et need tagaksid uue süsteemi tõhusama toimimise ja integreerimise.

4. Kirjeldage organisatsiooni struktuuri ja mõelge, kas see sobib kõige paremini ettevõtte eesmärkidega.

5. Uurige kõige tõhusamaid meetodeid, mida tööstuses kasutatakse.

Tagada vajaliku tehnilise infrastruktuuri loomine:

1. Laske asjakohastel ekspertidel hinnata praegust infrastruktuuri uue süsteemi nõuete alusel. Määratlege infosüsteemide osakonna roll ja kaaluge, milliseid muudatusi see uues keskkonnas läbi teeb.

2. Tehke loetletud piirkondades vajalikud muudatused enne süsteemi tootmisse viimist. Veenduge, et süsteem vastaks kõigi kasutajate põhivajadustele.

3. Dokumenteerige ettevõtte vajadused piisavalt üksikasjalikult, et võrrelda üht süsteemi teisega.

4. Kasutage saadud dokumente, et tagada rakendatud funktsioonide vastavus vajadustele.

Juhtida muutusi töötajatega kohanedes.

1. Tehke muudatusi järk-järgult, unustamata, et töötajad saavad korraga hallata vaid teatud hulga teavet.

2. Kaasake kõik, kes mängivad projekti algusest peale suurt rolli. Hea viis selleks on paluda neil ettevõtte vajaduste üksikasjaliku määratlemise osana sõna sekka öelda.

3. Suhtle selliste töötajatega regulaarselt, andes neile võimaluse olla ära kuulatud.

4. Töötage välja koolitusplaan, et inimesed mitte ainult ei õpiks andmeid süsteemi sisestama, vaid mõistaksid, kuidas nende töö muutub.

Pärast tegevuste lõpetamist saate otse süsteemi juurutamise juurde minna.

2.4. Infosüsteemi juurutamise etapid

Infosüsteemi rakendamisel tuleks eristada kolme etappi:

1. Uurimine. Rakendusettevõte viib läbi uuringu teie ettevõtte äriprotsesside kohta.

2. Süsteemi viimistlemine. Rakendusettevõtte programmeerijad seadistavad või muudavad süsteemi vajalikku funktsionaalsust.

3. Süsteemi käivitamine. Süsteemi reaalse kasutamise algus hõlmab personali koolitusprotsesse.

Äriprotsesside uurimine.

Iga süsteemitarnija ettevõte eraldab teatud aja, et uurida selle ettevõtte äriprotsesse, kus infosüsteemi rakendatakse.

Selles etapis on vaja ettevõtte esindajatele võimalikult täpselt kirjeldada, milliseid protsesse on vaja täiustada.

Infosüsteemi funktsionaalsus on reeglina mõnevõrra laiem kui ettevõtte tegelikud äriprotsessid. Selles etapis on vaja kindlaks teha, kuidas teatud funktsioonide olemasolu mõjutab süsteemi lõplikku maksumust, juurutamise aega ja mis kõige tähtsam, kas pakutav funktsionaalsus vastab ettevõtte eesmärkidele.

Oluline on, et äriprotsesside uuringute tulemused esitataks eraldi dokumendina, kus vastavalt ettevõtte nõuetele tuleks uuritavad äriprotsessid üksikasjalikult kirjeldada.

Süsteemi täiustamine.

Pärast äriprotsesside uurimist peab tarnija ettevõte täpselt vastama küsimusele infosüsteemi juurutamise maksumuse ja ajastuse kohta.

Süsteemi valmimise etapis on oluline kontrollida infosüsteemis vajalike funktsioonide juurutamise protsessi. Vajalik on kontrollida juurutuse vastavust ettevõtte nõuetele ning vajadusel kasutada kehtestatud mehhanismi rakendava ettevõtte mõjutamiseks.

Oluline on, et ettevõttel oleks juurutusprojekti juht, kes on hästi kursis ettevõtte eesmärkide ja äriprotsessidega. Tuleb mõista, et sellel inimesel peab olema ka kogemus selliste süsteemide juurutamise toetamisel ettevõttes.

Süsteemi käivitamine.

Selles etapis on oluline viia ettevõtte äriprotsessid kasutusele rakendatud süsteemile. Peamine ülesanne on personali kiire koolitamine ja motiveerimine uut infosüsteemi kasutama.

Paljud infosüsteemide juurutamise projektid on ebaõnnestunud või ei toonud soovitud tulemusi inimeste vastumeelsuse tõttu uut ebamugavat süsteemi kasutada, on vaja läbi viia koolitus ja näidata, kuidas süsteemi kasutamine võimaldab vabaneda rutiinsetest ülesannetest ja optimeerida. tööd.

Infosüsteemi arendamine.

Rakendatud süsteem reeglina kohe tööle ei hakka. Vajalik on analüüsida, kui edukas oli juurutamine ja kas juurutamise peamised eesmärgid said täidetud.

Rakendamist saab lugeda edukaks ainult siis, kui süsteem võimaldab teil saada eeliseid, nimelt optimeerib teenuste toimimist, võimaldab teil tööd kiiremini lõpetada ja tõstab protsesside kvaliteeti. Pidevalt on vaja analüüsida süsteemi jõudlust ja ka personali huvi selle süsteemi kasutamise vastu.

Infosüsteemi juurutamise protsess võtab aega vähemalt mitu kuud. Selle aja jooksul on oluline keskenduda eesmärkidele, mida teie ettevõte soovib süsteemi juurutamisel saavutada, samuti tuleb meeles pidada võimalikke riske ja finantskulusid. Korraldage oma tööd õigesti ja infosüsteemi juurutamine teie ettevõttes sujub edukalt.

Z järeldus

Infotehnoloogia kasutamine ettevõtte juhtimisel muudab iga ettevõtte konkurentsivõimelisemaks, suurendades selle juhitavust ja kohanemisvõimet turutingimuste muutustega. Selline automatiseerimine võimaldab teil:

Suurendage ettevõtte juhtimise efektiivsust, pakkudes juhtidele ja spetsialistidele kõige täielikumat, õigeaegsemat ja usaldusväärsemat teavet ühe andmepanga alusel.

Vähendage ärikulusid, automatiseerides infotöötlusprotsesse, reguleerides ja lihtsustades ettevõtte töötajate juurdepääsu vajalikule teabele. Muutke töötajate töö iseloomu, vabastades nad rutiinsest tööst ja andes neile võimaluse keskenduda professionaalselt olulistele kohustustele.

Tagada kõigil juhtimistasanditel raha laekumiste ja väljaminekute usaldusväärne arvestus ja kontroll.

Kesk- ja madalama taseme juhid analüüsivad oma osakondade tegevust ning koostavad operatiivselt juhtkonnale ja sellega seotud osakondadele koond- ja analüütilised aruanded.

Tõsta andmevahetuse efektiivsust üksikute osakondade, filiaalide ja keskkontori vahel.

Tagage andmete täielik turvalisus ja terviklikkus teabe töötlemise kõigil etappidel.

Automatiseerimine annab integreeritud lähenemisviisiga palju suurema efekti. Üksikute tööde või funktsioonide osaline automatiseerimine võib lahendada ainult teise “põleva” probleemi. Samas ilmnevad ka negatiivsed mõjud: tööjõumahukus ja personali ülalpidamiskulud ei vähene, vahel isegi suurenevad; osakondade töö ebajärjekindlust ei kõrvaldata.

Seega on ettevõtte juhtimissüsteemi edukaks rakendamiseks vaja:

Süsteemi valikul ärge lähtuge selle olemasolust turul, vaid sellest, kui sobiv see on ettevõtte ärivajaduste rahuldamiseks;

Mine juurutusse tugeva projektijuhi ja hoolikalt läbimõeldud projektiplaaniga;

Enne süsteemi valimist vaadake üle ettevõtte äritavad;

Suhtlema regulaarselt töötajatega, püüdes neid kaasata süsteemi juurutamisse ja võimaldada neil tagada nende vajadustega arvestamine;

Jälgida projekti kulgu, kontrollides planeeritud verstaposte ja ülesannete täitmise tähtaegu;

Määrake realistlikud tähtajad ja koostage mõistlik eelarve;

Viia infosüsteemide osakonna töötajate väljaõppe tase vastavusse uute nõuetega;

Usalda projekti elluviimine inimesele, kes tunneb Sinu ettevõtte tegevust seestpoolt.

Standardse rakendusplaani töötas välja Oliver Wight, kuid kogemused näitavad, et ühel või teisel määral järgivad seda strateegiat peaaegu kõik ettevõtted.

See plaan koosneb järgmistest etappidest:

1. Ettevõtte seisundi eelkontroll ja hindamine;

2. Eelnev ümberõpe;

3. Tehnilised kirjeldused (süsteemi ülesehitamise probleemi analüüs);

4. Teostatavusuuring (kulu-efekti analüüs);

5. Projekti korraldus (vastutajate määramine, komisjonide koosseis);

6. Eesmärkide väljatöötamine (mida me projektilt ootame);

7. Protsessi juhtimise lähteülesanne;

8. Esmane ümberõpe (töötajate ümberõpe);

9. Tipptasemel planeerimine ja juhtimine;

10. Andmehaldus;

11. Erinevate organiseerimis- ja juhtimistehnoloogiate samaaegne juurutamine;

12. Tarkvara;

13. Kogenud eeskuju;

14. Tulemuste saamine;

15. Hetkeseisu analüüs;

16. Pidev ümberõpe.

Infotehnoloogiad, hoolimata oma revolutsioonilisusest, ei ole kaotanud tootmisprotsessi, pole kõrvaldanud konkurente ega võtnud inimeselt otsustusõigust. Juhtimise objekt - ettevõte ei ole lakanud olemast, isegi kui see on muutunud virtuaalseks, väliskeskkond eksisteerib edasi ja on isegi suurenenud, säilib vajadus leida lahendusi poolstruktureeritud probleemidele. Pigem saame rääkida kõigi protsesside intensiivistumisest infoajastul. Ettevõtte juhtimise tööriistad on muutunud, kuid need on nii palju muutunud, et on mõjutanud kõiki protsesse, millega juhid on seotud: planeerimine, organiseerimine, juhtimine ja kontroll.

Allikate loend:

1. Baranovskaja T. P. jt Infosüsteemid ja tehnoloogiad majanduses Kirjastaja: Finance and Statistics, 416 lk, 2003

2. Baronov V.P., Titovsky I.L., artikkel “Juhtimissüsteemide ehitamise meetodid”

3. Bozhko V. P. Infotehnoloogiad statistikas Väljaandja: Finstatinform, KnoRus, 144 lk., 2002

4. Verevchenko A.P. jt Teabeallikad otsuste tegemiseks Kirjastajad: Business Book, Academic Project; 560 lk, 2002

5. Volokitin A.V. jt Informatiseerimisvahendid valitsusasutustele ja äriettevõtetele. Teatmik Kirjastus: FIORD-INFO 272 lk., 2002

6. Gaskarov D.V. Intelligentsed infosüsteemid Väljaandja: Vysshaya Shkola, 432 lk, 2003

7. Gerasimova L.N. Turunduse teabetugi Väljaandja: Marketing, 120 lk, 2004

8. Godin V.V., Korneev I.K. Juhtimistegevuse infotugi Väljaandjad: Kõrgkool, magistriõpe; 240 lk, 2001

9. Grinberg A. S., Korol I. A. Infohaldus Kirjastaja: Unity-Dana; 416 lk, 2003

10. Grinberg A. S., Shestakov V. M. Infotehnoloogiad majandusjuhtimisprotsesside modelleerimiseks Kirjastaja: Unity-Dana; 400 lk, 2003

11. Dushin V.K. Infoprotsesside ja -süsteemide teoreetilised alused Kirjastaja: Dashkov and Co., 250 lk, 2002

12. Kalyanov G. N. Konsulteerimine: äristrateegiast ettevõtte teabe- ja juhtimissüsteemini Väljaandja: Hot Line - Telecom 208 lk., 2004

13. Karabutov N. N. Infotehnoloogiad majanduses Kirjastaja: Ekonomika; 208 lk, 2003

14. Kogalovsky M. R. Infosüsteemide arenenud tehnoloogiad Kirjastaja: DMK Press, IT Company; 288 lk, 2003

15. Kolesnikov S.I., artikkel “ERP-süsteemide juurutamise ja kasutamise tõhususe hindamisest”

16. Lipaev V.V Infosüsteemide komplekstarkvara süsteemiprojekteerimine Väljaandja: Sinteg; 268 lk, 2002

17. Michael J. D. Sutton Ettevõtte dokumendihaldus. Põhimõtted, tehnoloogiad, teostusmetoodika

18. Kirjastus: Micro, Azbuka, 446 lk, 2002

19. Maklakov S. V. Äriprotsesside modelleerimine Kirjastaja: Dialog - MEPhI, 240 lk., 2003

20. Menjajev M. F. Juhtimise infotehnoloogiad. Raamat 3. Organisatsiooni juhtimissüsteemid, 464 lk, 2003.

21. Patrushina S. M. Infosüsteemid majanduses. Kirjastaja: Business, 352 lk, 2004

22. Prokusheva A. P., Lipatnikova T. F., Kolesnikova N. A. Infotehnoloogiad äritegevuses Väljaandja: Marketing, 192 lk, 2001

23. Rodionov I. I. jne Infoteenuste ja -toodete turg Väljaandja: MK-Perioodika 552 lk, 2002

24. Sar Ermako Jonii, artikkel “Olla või mitte olla ERP?”

25. Sinyuk V.G., Shevyrev A.V. Info- ja analüütiliste tehnoloogiate kasutamine juhtimisotsuste tegemisel Kirjastaja: DMK Press; 160 lk, 2003

26. Skripkin K. G. Infosüsteemide majanduslik efektiivsus Kirjastaja: DMK Press; 256 lk, 2002

27. Strelets I. A. Uus majandusteadus ja infotehnoloogia Kirjastaja: Eksam, 256 lk, 2003

28. Utkin V. B., Baldin K. V. Infosüsteemid majanduses Kirjastus: Finance and Statistics, 288 lk., 2004

29. Khoroshilov A.V., S.N. Seletkov Maailma teabeallikad Kirjastaja: Peter; 176 lk, 2004

30. Shafrin Infotehnoloogiad. 2. osa Kirjastaja: Binom. Teadmiste labor; 320 lk, 2002

31. Eriksen T. H. Hetke türannia. Aeg infoajastul Kirjastaja: Ves Mir, 208 lk., 2003

Saitidelt kasutatud materjalid:

32. www.altrc.ru

33. www.bankreferatov.ru

34. www.economics.ru

35. www.erp-people.com

39. www.parus.ru