Інформаційні системи в міжнародному бізнесі

Інформаційні системи в міжнародному бізнесі

Код буквений цифровий28 Боснія і Герцеговина BOSNIA HERZG BIH 07029 Ботсвана BOTSWANA BWA 07230 Бразилія BRAZIL BRA 07631 Брит.тер. в Інд.океані BR.IND.OC.TR IOT 08632 Бруней Даруссалам BRUNEI DARSM BRN 09633 Буркіна-Фасо BURKINA FASO BFA 85434 Бурунді BURUNDI BDI 10835 Бутан BHUTAN BTN 06436 Буве BVT 07437 Вануату VANUATU VUT 54838 Ватікан HOLY SEE VAT 33639 Великобританія UK GBR 82640 Венесуела VENESUELA VEN 86241 В’єтнам VIET NAM VNM 70442 Віргінські о-ви (Брит.) BR.VIRGIN IS VGB 09243 Віргінські о-ви (США) US.VIRGIN VIR 85044 Вірменія ARMENIA ARM 05145 Габон GABON GAB 26646 Газа Сектор (Палестина) GAZA STRIP 27447 Гаїті HAITI HTI 33248 Гайана GUYANA GUY 32849 Гамбія GAMBIA GMB 27050 Гана GHANA GHA 28851 Гваделупа GUADELOUPE GLP 31252 Гватемала GUATEMALA GTM 32053 Гвіана (Фр.) FR.GUIANA GUF 25454 Гвінея GUINEA GIN 32455 Гвінея-Бісау GUINEABISSAU GNB 62456 Гібралтар GIBRALTAR GIB 29257 Гондурас HONDURAS HND 34058 Гонконг (Сянган) HONG KONG HKG 34459 Гренада GRENADA GRD 30860 Гренландія GREENLAND GRL 30461 Греція GREECE GRC 30062 Грузія GEORGIA GEO 26863 Гуам (США) GUAM GUM 31664 Данія DENMARK DNK 20865 Джібуді DJIBOUTI DJI 26266 Джонстон о-в JOHNSTON IS JTN 39667 Домініка DOMINICA DMA 21268 Домініканська Респ. DOMINICAN RP DOM 21469 Еквадор ECUADOR ECU 21870 Екваторіальна Гвінея EQ.GUINEA GNQ 22671 Естонія ESTONIA EST 23372 Ефіопія ETHIOPIA ETH 23073 Ерітрея ERITREA ERI 23274 Єгіпет EGYPT EGY 81875 Заїр ZAIR ZAR 18076 Замбія ZAMBIA ZMB 89477 Західна Сахара WESTN.SAHARA ESH 73278 Зімбабве ZIMBABWE ZWE 71679 Ізраїль ISRAEL AZR 37680 Індія INDIA IND 35681 Індонезія INDONESIA IDN 36082 Ірак IRAQ IRQ 368Продовження табл. 3.7

Код буквений цифровий83 Іран IRAN IRN 36484 Ірландія IRELAND IRL 37285 Ісландія ICELAND ISL 35286 Іспанія SPAIN ESP 72487 Італія ITALY ITA 38088 Йємен YEMEN YEM 88789 Йорданія JORDAN JOR 40090 Кабо-Верде CAPO VERDE CPV 13291 Казахстан KAZAKHSTAN KAZ 39892 Кайман о-в CAYMAN IS CYM 13693 Камбоджа CAMBODIA KHM 11694 Камерун CAMEROON CMR 12095 Канада CANADA CAN 12496 Катар QATAR QAT 63497 Кенія KENIYA KEN 40498 Киргизстан KYRGYZSTAN KGZ 41799 Китай CHINA CHN 156100 Кіпр CYPRUS CYP 196101 Кірібаті KIRIBATI KIR 296102 Кокосові о-ви COCOS IS CCK 166103 Колумбія COLOMBIA COL 170104 Коморські о-ви COMOROS COM 174105 Конго CONGO COG 178106 Корея (КНДР) KOREA DPRP PRK 408107 Корея (Південна) KOREA REP. KOR 410108 Коста-Ріка COSTA RICA CRI 188109 Кот-д’Івуар COTE DIVOIRE CIV 384110 Куба CUBA CUB 192111 Кувейт KUWAIT KWT 414112 Кука о-ви COOK IS COK 184113 Лаос LAO P.DEM.R. LAO 418114 Латвія LATVIA LVA 428115 Лєсото LESOTHO LSO 426116 Литва LITHUANIA LTU 440117 Ліберія LIDERIA LBR 430118 Ліван LEBANON LBN 422119 Лівія LIBYA LBY 434120 Ліхтенштейн LIECHTENSTEN LIE 438121 Люксембург LUXEMBOURG LUX 442122 Маврикій MAURITIUS MUS 480123 Мавританія MAURITANIA MRT 478124 Мадагаскар MADAGASCAR MDG 450125 Македонія MACEDONIA MKD 807126 Малаві MALAWI MWI 454127 Малайзія MALAYSIA MYS 458128 Малі MALI MLI 466129 Малі Тихоокеанські о-ви UMI 581130 Мальдіви MALDIVES MDV 462131 Мальта MALTA MLT 470132 Маріанські (Півн.) о-ви N.MARIANA IS MNP 580133 Марокко MAROCCO MAR 504134 Мартініка MARTINIQUE MTQ 474135 Маршалові о-ви MARSHALL IS MHL 584136 Мексика MEXICO MEX 484137 Мікронезія MICRONTSIA FSM 583Продовження табл. 3.7

Код буквений цифровий138 Мідуей о-ви MIDWAY IS MID 488139 Мозамбік MOZAMBIQUE MOZ 508140 Молдова REP MOLDOVA MDA 498141 Монако MONACO MCO 492142 Монголія MONGOLIA MNG 496143 Монтсеррат MONTSERRAT MSR 500144 Мьянма MYANMAR MMR 104145 Намібія NAMIBIA NAM 516146 Науру NAURU NRU 520147 Непал NEPAL NPL 524148 Нігер NIGER NER 562149 Нігерія NIGERIA NGA 566150 Нідерланди NETHERLANDS NLD 528151 Нікарагуа NICARAGUA NIC 558152 Німеччина GERMANY DEU 276153 Ніуе о-ви NIUE NIU 570154 Нова Зеландія NEW ZELAND NZL 554155 Нова Каледонія NEW CALEDONIA NCL 540156 Норвегія NORWAY NOR 578157 Нормандські о-ви CHANNEL IS 830158 Норфолк о-в NORFOLK IS NFK 574159 О.А.Емірати UNTD ARAB EM ARE 784160 Оман OMAN OMN 512161 О-в Мен ISLE OF MAN IMY 833162 Пакистан PAKISTAN PAK 586163 Палау о-ви PALAU PLW 585164 Панама PANAMA PAN 591165 Папуа-Нова Гвінея PAPUA N.GUIN PNG 598166 Парагвай PARAGUAY PRY 600167 Перу PERU PER 604168 Південноафр.республіка SOUTH AFRICA ZAF 710169 Піткерн о-в (Брит.) PITCARN PCN 612170 Польща POLAND POL 616171 Португалія PORTUGAL PRT 620172 Пуерто-Ріко PUERTO RICO PRI 630173 Реюньйон REUNION REU 638174 Різдва о-в (Австрал.) CHRISTMAS IS CXR 162175 Росія RUSSIAN FED RUS 643176 Руанда RWANDA RWA 646177 Румунія ROMANIA ROM 642178 Сальвадор EL SALVADOR SLV 222179 Самоа (західне) SAMOA WSM 882180 Сан-Маріно SAN MARINO SMR 674181 Сан-Томе і Прінсіпі SAO TOME PRN STP 678182 Саудівська Аравія SAUDI ARABIA SAU 682183 Свазіленд SWAZILAND SWZ 748184 Святої Єлени о-в ST.HELENA SHN 654185 Сейшельські о-ви SEYSHELLES SYC 690186 Сенегал SENEGAL SEN 686187 С. -П’єр і Мікелон ST.PIERRE.MQ SPM 666188 С. -Вінсент і Гренадіни ST.VINCENT.G VCT 670189 С. -Кітс і Невіс ST.KITTS-NEV KNA 659Закінчення табл. 3.7

Код буквений цифровий190 С. -Люсія ST.LUCIA LCA 662191 Сінгапур SINGAPORE SGP 702192 Сірія SYRIA SYR 760193 Словакія SLOVAKIA SVK 703194 Словенія SLOVENIA SVN 705195 Соломонови о-ви SOLOMON IS SLB 090196 Сомалі SOMALIA SOM 706197 США USA USA 840198 Судан SUDAN SDN 736199 Сурінам SURINAM SUR 740200 Східний Тімор EAST TIMOR TMP 626201 Сьєрра-Леоне SIERRA LEONE SLE 694202 Таджикистан TAJIKISTAN TJK 762203 Таїланд THAILAND THA 764204 Тайвань (у складі Китаю) TAIWAN TWN 158205 Танзанія TANZANIA TZA 834206 Теркс і Кайкос о-ви TURKS, CAICOS TCA 796207 Того TOGO TGO 768208 Токелау TOKELAU TKL 772209 Тонга TONGA TON 776210 Трінідад і Тобаго TRINIDAD TBG TTO 780211 Тувалу TUVALU TUV 798212 Туніс TUNISIA TUN 788213 Туреччина TURKEY TUR 792214 Туркменистан TURKMENISTAN TKM 795215 Уганда UGANDA UGA 800216 Уейк о-в WAKE IS WAK 872217 Угорщина HUNGARY HUN 348218 Узбекистан UZBEKISTAN UZB 860219 Україна UKRAINE UKR 804220 Уоллис і Футуна о-ви WALLIS FUT.IS WLF 876221 Уругвай URUGUAY URY 858222 Фарерські о-ви FAEROE IS FRO 234223 Фіджі FIJI FJI 242224 Філіппіни PHILIPPINES PHL 608225 Фінляндія FINLAND FIN 246226 Фолклендські о-ви FALKLAND FLK 238227 Франція FRANCE FRA 250228 Фр.Полінезія FR.POLYNESIA PYF 258229 Фр.Південні території ATF 260230 Херд і Макдональд HMD 334231 Хорватія CROATIA HRV 191232 Центральноафр.Респуб. CENT.AFR.REP CAF 140233 Чад CHAD TCD 148234 Чехія CZECHIA 203235 Чилі CHILE CHL 152236 Швейцарія SWITHERLAND CHE 756237 Швеція SWEDEN SWE 752238 Шпіцберген і Ян Майєн SVALBARD IS SJM 744239 Шрі-Ланка SRI LANKA LKA 144240 Югославія (Сербія,Чорногорія) YUGOSLAVIA YUG 891241 Ямайка JAMAICA JAM 388242 Японія JAPAN JPN 3923.5. СИСТЕМИ ШТРИХОВОГО КОДУВАННЯ ТОВАРІВЗ розвитком виробництва і збільшенням товарообігу виникла проблема пошуку універсальних засобів маркірування, які б дозволили визначати рух товарів на шляху від виробника до споживача. Передбачалося, що маркіровка повинна бути про-стою й доступною для нанесення на упаковку, нести необхідний мінімум інформації, іншими словами, давати змогу ідентифіку-вати товар. Водночас зазначена маркіровка має легко й безпо-милково читатися за допомогою відносно простих, надійних і недорогих технічних засобів, доступних для придбання підпри-ємствами. Поєднання подібних засобів з обчислювальною тех-нікою, її необмеженими можливостями з нагромадження, обробки й передачі інформації дозволило б вийти на якісно новий рівень автоматичної ідентифікації товарів.Таким універсальним засобом маркіровки, яка характеризує споживчі властивості товару і несе інформацію про його виробника, стала невелика смужка на упаковці, що являє собою чергування темних і світлих штрихів різної ширини, під якими розміщені цифри, інколи цифри й букви — так званий «штри-ховий код».Повертаючись до питання щодо введення інформації в ЕОМ, слід зазначити, що найпростіший спосіб введення реалізується за допомогою клавіатури, однак він не зовсім досконалий. Навіть висококваліфікований оператор ЕОМ фізично не може досить швидко і безпомилково ввести інформацію в машину. За даними статистики, оператор робить у середньому одну помилку на 300 знаків.Зовсім інші результати дає автоматизоване зчитування інформації, яку відображають штрихові коди. При цьому швид-кість, порівняно з ручним введенням, зростає в десятки, а віро-гідність — у сотні разів.Уперше штрихове кодування стало застосовуватись у США в 60-ті роки для ідентифікації залізничних вагонів. У 1973 р. універсальний код UPC (Universal Product Code) набув поширен-ня в промисловості й торгівлі. У 1977 р. штриховий код з’явля-ється в Європі. Цей рік став датою народження Європейської системи кодування товарів EAN (European Artiсle Numbering).Асоціація EAN у 1987 р. виділила СРСР десять тризначних кодів — з 460 по 469. Наприкінці 1990 р. 14 підприємств, розта-шованих на території колишнього СРСР, вирішили об’єднати свої зусилля й створили зовнішньоекономічну асоціацію ЮНІСКАН.Одним із основних напрямків роботи асоціації ЮНІСКАН є надання практичної допомоги промисловим, сільськогосподар-ським, транспортним та іншим організаціям щодо впровадження систем автоматичної ідентифікації та штрихового кодування.Асоціація ЮНІСКАН як член EAN видає підприємствам реєстраційні номери в системі EAN і веде відповідні банки даних. Для підприємств України спочатку було виділено код 465, а пізніше 482. В Україні створено подібну організацію СКАН, яка поки що не є членом EAN. Тому за спільною домовленістю реєстраційні номери підприємствам України видає асоціація ЮНІСКАН.Штрихове кодування в країнах далекого зарубіжжя широко використовується в комерційній діяльності, оптовій і роздрібній торгівлі, сфері послуг. У США 90 % товарів, які виробляються, несуть на упаковці штриховний код, у Німеччині — 80%, у Франції — близько 70 %. Використання інформації, отриманої зчитуванням штрихових кодів, — сьогодні одна з найпривабливіших технологій автоматичної ідентифікації. Це пояснюється низькою вартістю, а також можливістю нанесення й зчитування коду практично з будь-якого предмета.Розглянемо різновиди кодів, які застосовуються в різних сферах людської діяльності:— коди сім’ї 2 із 5 (ITF);— код Codabar;— код 39;— код 93;— код 128;— коди сім’ї UPC (UPC-A, UPC-Е);— коди сім’ї EAN (EAN-8, EAN-13);— код JAN (Japan Artiсle Numbering);— код NCB (багатокомірковий код);— коди підвищеної щільності (мозаїчний, PDF-417).Кожний код має свою галузь застосування, правила нанесення і використання. Найбільшого поширення набули коди сім’ї EAN.Штрихове кодування являє собою систему збирання даних (цифр, букв, інших знаків), записаних у вигляді штрихів і пробілів. Носієм закодованої інформації є відносна ширина темних і світлих смужок. Основна одиниця інформації штрихового коду — знак. Знак складається із штрихів і пробілів (найвужчий з них прийнято називати модулем. Наприклад, у системі EAN-13 знак складається із семи модулів).Кожному типу товару присвоюється номер, який найчастіше складається з 13 цифр (рис. 3.1) (EAN-13). Жодний інший товар, який обертається в міжнародній торгівлі, не може мати такий самий номер. Отже, що саме означають ці 13 цифр? Для відповіді на це запитання розглянемо рисунок.

Рис. 3.1. Штрихове кодування товарів

Перші дві цифри (40) — так звані «прапори» — присвоюються країнам які входять до EAN, штаб-квартира якої знаходиться в Брюсселі. Наступні п’ять цифр (12345) присвоюються націо¬нальними відомствами підприємству, яке виробляє або реалізує продукт. І ще п’ять цифр (98765) присвоюються товару безпосередньо самим підприємством з урахуванням його споживчих властивостей, розмірів, кольору, упаковки. І остання цифра (2) — контрольна — використовується для перевірки правильності зчитування штрихового коду спеціальним пристроєм — сканером. Можливий також варіант, коли для коду країни-виробника відводиться три знаки, а для коду підприємств — чотири.Прапори країн наведено в табл. 3.8.Таблиця 3.8ЗНАЧЕННЯ «ПРАПОРІВ» EAN№ п/п Країна Значення «прапору»1 США і Канада 00, 01, 03, 04, 062 Резерв EAN 20–293 Франція 30–374 ФРН 40–435 СРСР в т.ч. 46.0–46.9 Україна 4656 Тайвань 47.17 Японія 498 Великобританія і Північна Ірландія 509 Греція 52.010 Кіпр 52.911 Бельгія і Люксембург 5412 Португалія 56.013 Ісландія 56.914 Данія 5715 Угорщина 59.916 ЮАР 60.0–60.117 Фінляндія 6418 Норвегія 7019 Ізраїль 72.920 Швеція 7321 Мексика 75.022 Швейцарія 7623 Аргентина 77.924 Бразилія 78.925 Італія 80–8326 Іспанія 8427 Чехословаччина 85.928 Югославія 86.029 Турція 86.930 Нідерланди 8731 Сінгапур 88.832 Австрія 90–9133 Австралія 9334 Нова Зеландія 9435 Папуа-Нова Гвінея 95.936 Періодичні видання (ISSN) 97.737 Книжки (ISSN) 97.8–97.938 Купони 98–99Коди EAN можуть відображати лише цифрову інформацію, що обмежує галузь їх застосування в основному сферою тор-гівлі. У виробництві, медицині, поштово-пакункових відправ-леннях, бібліотечній справі застосовуються інші типи штрихових кодів, у яких зберігається загальний принцип: чергування темних і світлих смужок різної ширини, але конкретна система кодування для кожного коду індивідуальна. Яку ж користь мають власники торгових точок при впровадженні штрихового кодування і оснащенні магазинів електронно-реєструючими апаратами?По-перше, це збільшення продажу, а отже, прибутку на 1–1,5%. Це залежить від інформованості власника про ціни. Краща інформація дає змогу укласти більш вигодні угоди. По-друге, зменшення на 2–5% обслуговуючого персоналу. Це важливий чинник.При використанні цієї системи немає потреби виконувати ручну роботу, підраховувати кількість замовлень і прибуток. Ще один найбільш важливий чинник — зменшення «усадки». Цей термін використовується замість слова «крадіжка». Випадки крадіжок зменшуються на 10–30% завдяки більш легкому іденти¬фікуванню товарів.Звичайне повернення капіталу при використанні штрихових кодів досягає 30%. Це означає, що на кожні вкладені $ 100 буде отримано $ 130 прибутку. Отже, витрати на штрихове кодування і оснащення торгових підприємств електронно-касовою технікою є необхідною і прибутковою справою.

4. ДЕРЖАВНА ПОЛІТИКА В ГАЛУЗІСТВОРЕННЯ АВТОМАТИЗОВАНИХ ІНФОРМАЦІЙНИЙСИСТЕМ ЗА КОРДОНОМ

Перед тим як перейти безпосередньо до розгляду всіх аспектів, пов’язаних зі створенням інформаційних систем для міжна¬родного бізнесу, автори вважають за доцільне розглянути питання державної політики в галузі інформатизації в промислового розвинених країнах світу, насамперед у таких, як США, Великобританія та ін. Щодо державної політики, передусім необ¬хідно мати на увазі:— принципи й концептуальні підходи до інформатизації суспільства;— створення законодавчих нормативних актів, які б регламентували всі види діяльності в галузі інформатизації (насам¬перед створення відповідних стандартів);— розробку ефективних технологій створення автоматизованих інформаційних систем;— питання забезпечення захисту інформації в інформаційних системах.4.1. ПОРІВНЯЛЬНА ХАРАКТЕРИСТИКА АМЕРИКАНСЬКОГО І БРИТАНСЬКОГО ПІДХОДІВ ДО ДЕРЖАВНОГОРЕГУЛЮВАННЯ В ОБЛАСТІ ІНФОРМАТИЗАЦІЇСьогодення характерне тим, що в діяльності промислово розвинених країн світу досить чітко сформувались державна полі¬тика в галузі інформатизації. Особливо яскраво вона прояв-ляється в США і Великобританії.Стосовно США це пояснюється, з одного боку, значним впливом військово-промислового комплексу, а з іншого — стур-бованістю громадськості необхідністю державного контролю за ефективними витратами бюджетних асигнувань, спрямованих на створення автоматизованих систем (АС), насамперед за замовленнями Міністерства оборони США й NASA. Зараз в цій країні державну політику в галузі інформатизації в основному визначає Міністерство оборони. Це відомство є найбільшим в світі замовником засобів обчислювальної техніки та програмного забезпечення. Досить сказати, що відповідна стаття витрат Міністерства оборони дорівнює сумарним витратам на АС 20 інших найбільших замовників у США. Для розробки органі-заційно-методичних основ політики з питань інформатизації цим відомством у 1984 р. був створений і постійно фінансується спе-ціальний науково-технічний центр — Інститут програмної інже-нерії (SEI).Решта федеральних відомств, що витрачають значні кошти держбюджету на розробку АС (NASA, Федеральне агентство цивільної авіації, Міністерство енергетики та ін.), мають у своє¬му складі невеликі координаційні органи.Питання стандартизації в галузі телекомунікацій та інформа-ційних технологій в США вирішуються немов би в двох площинах. По-перше, як і в інших галузях американської промисловості, основну масу стандартів розробляють такі громадські організації, як Інститут інженерів з електротехніки і електроніки (ІЕЕЕ). Зокрема, існують стандарти на мови програмування COBOL, PASCAL, FORTRAN, а також на систему контролю й забезпечення якості та організацію управління проектами створення АС. Деякі з цих стандартів навіть отримали статус міжна¬родних під егідою ISO. Однак, механізмом реалізації дії більшості з цих стандартів виступає ринок, оскільки держава не контролює їх дотримання. По-друге, на загальнодержавному рівні за стандартизацію відповідає Національний інститут стандартизації і технологій (зараз NIST; у минулому — ANSI), але в сфері його компетенції перебуває лише досить вузьке коло питань.Отже, на сьогодні органу, який би формував у США єдину загальнодержавну політику з питань інформатизації, поки що не існує. Необхідність у такій політиці поступово усвідомлюється американськими спеціалістами. Зокрема, зараз NIST і Націо-нальний фонд наукових досліджень (NSF) намагаються виробити основи такої політики. У цій діяльності беруть активну участь такі впливові громадські організації, як ІЕЕЕ, Асоціація з об-числювальної техніки (АСМ) і Асоціація наукових досліджень у галузі обчислювальної техніки (СRA). Однак на сьогодні відпо-відного рішення на урядовому рівні поки що не прийнято. Саме тому, якщо вести мову про державну політику США в галузі інформатизації, слід мати на увазі винятково політику Міністер-ства оборони, основні організаційно-методичні проблеми якої розробляє інститут SEI.Можна назвати три групи питань, які досить успішно розв’я-зані в США і знайшли своє відображення в державній технічній політиці в галузі інформатизації:— система сертифікації організацій — розробників АС;— стандартизація порядку створення АС військового призначення;— стандартизація систем програмування Ада.На відміну від США, у Великобританії наприкінці 70-х років у рамках Міністерства суспільної праці було створено спеціаль-ний загальнодержавний орган — Центральне агентство з питань обчислювальної техніки і телекомунікації (ССТА), якому було доручено розробку і впровадження єди¬ної технічної політики. Більш висока, ніж у США, частка державного сектору, менші масштаби країни й менша різноманітність, точніше практична відсутність на той час розвинених технологій промислової розробки АС у Великобританії в поєднанні з розумною політикою ССТА, дали змогу цьому відомству оволодіти в досить короткий термін ситуацією та реалізувати доволі жорстке центра¬лізоване регулювання в галузі інформатизації. Базовим принципом такої політики стало закріплення в державних стандартах передових методів і технологій, а також створення механізму, який би забезпечив їх суворе дотримування організаціями — розробниками АС.У 1978–1979 рр. на замовлення ССТА фірмами Model Systems Ltd i LBMS Plc було розроблено першу версію технології створення АС, яка дістала назву «Технологія структурного аналізу і проектування систем» (Structured Systems Analysis and Design Method — SSADM). Починаючи з 1980 р. рішенням уряду розробки всіх АС, що фінансуються з держбюджету, було рекомендовано проводити лише за цією технологією, яка отримала статус галузевого стандарту.Для створення механізму реалізації цього рішення уряду в ССТА було організовано спеціальний підрозділ — Design Autho-rity Board (DAB), який став безпосередньо курирувати питання впровадження, застосування і фінансування робіт по вдосконаленню технології SSADM. Зокрема, було встановлено порядок допуску організацій — розробників АС до виконання держзамовлень. Починаючи з 1980 р. організація, що претендувала на виконання держзамовлення, мала підтвердити те, що її співробітники достатньою мірою оволоділи на практиці технологією SSADM. Таким підтвердженням мав бути сертифікат, що видавався особисто кожному проектувальникові Комісією з атестації розробників АС (ISEB), заснованою ССТА. Згідно з правилами ССТА для отримання сертифікату претендент повинен [23]:— пройти курс перепідготовки з технології SSADM (не мен-ше 80 годин) в акредитованій організації;— мати досвід практичної роботи проектувальника АС не менш як один рік (у цьому разі досвід роботи програміста не зараховується);— мати вік не менше 23 років;— успішно здати усний і письмовий кваліфікаційні іспити на знання технології SSADM і вміння її застосувати на практиці.Заслуговує на увагу те, що сертифікат неможливо одержати лише в результаті самостійного вивчення технологічної доку-ментації — претендент повинен пройти курс навчання під керів-ництвом професіонала, що має високу кваліфікацію, підтвердже-ну спеціальною акредитацією організації, яку цей професіонал представляє.Описаний механізм реалізації урядового рішення про обов’яз¬кове застосування технології SSADM у промисловості створив попит на послуги з перепідготовки спеціалістів і консультації з проектування АС. Крім того, починаючи з 1980 р. з метою узагальнення досвіду використання технології SSADM і відслідко¬вування науково-технічних досягнень ССТА постійно фінансу¬вало науково-дослідні та дослідно-конструкторські роботи, спря¬мовані на вдосконалення цієї технології. Приміром, на початку 1990 р. було розроблено й прийнято вже її четверту версію, а в середині 1995 р. — оновлену версію 4.2. Під час кожної заміни офіційно прийнятої версії технології SSADM у Великобританії під контролем ISEB проводилась переатестація розробників, що забезпечувало постійний попит на відповідні послуги. Зараз у країні є близько 30 акредитованих організацій, що здійсню¬ють перепідготовку спеціалістів, і майже 300 організацій, які пропонують свої послуги як консультанти проектів створення АС або як їх виконавці. Питаннями стандартизацій, випробувань і контролю якості промислової продукції у Великобританії керує незалежна урядова організація — Британський інститут стандартів (BSI), заснований у 1929 р. У 1993 р. технологія SSADM була офіційно зареєстрована як державний стандарт BS 7738.У 1988 р. організації та окремі особи, зацікавлені в технології SSADM, створили незалежну асоціацію — Міжнародну групу користувачів SSADM (ISUG), яка діє на правах компанії з обмеженою відповідальністю. Асоціація два рази на рік проводить конференції, а також семінари й робочі зустрічі, на яких обговорюються актуальні організаційні та технічні питання використання і розвитку технології SSADM, координує діяльність заці¬кавлених груп користувачів цієї технології та видає щоквартальний інфор¬маційний бюлетень. Зараз асоціація налічує понад 450 колективних і близько 3000 індивідуальних членів. Загалом діяльність ISUG сприяла становленню технології SSADM як у Великобританії, так і за її межами. Британську технологію використовують у країнах Західної Європи, Гонконзі, Ізраїлі, а нещодавно вона також проникла в Східну Європу — Угорщину й Чехію, де вже отримала державну підтримку.Комплексність — це та важлива риса, яка принципово відріз-няє британський підхід до державного регулювання розробок АС. Вона, насамперед, проявляється в тому, що в країні, поряд з технологією SSADM, яка охоплює стадії створення інформацій-ного та програмного забезпечень, існує ще дві технології, що мають підтримку з боку ССТА і безпосереднє відношення до розробки АС за держзамовленнями. Перша з них — PRINCE (Projects’ IN Controlled Enrironments) — регламентує порядок управління проектами. Друга — CRAMM (CCTA Risks’ Assesse-ment and Managing Method) — визначає методики виявлення чинників ризику при створенні АС, оцінки їх впливу і порядок розробки контрзаходів, які б забезпечували потрібну надійність, безпеку та контрольованість створюваних АС. У Великобританії всі три технології — SSADM, PRINCE i CRAMM — являють собою єдиний пакет, що забезпечує їх концептуальну єдність і зручність у користуванні.Отже, в розвинених країнах світу, насамперед у США і Великобританії, впродовж двох останніх десятиліть досить ефективно здійснюється комплексне державне регулювання питань інфор¬матизації. Найбільш яскраво воно проявляється у створенні АС за держзамовленнями, особливо для військових відомств. Центральне місце в процесі державного регулювання посідають системи сертифікації організацій, що претендують на одержання держзамовлень, а також системи держстандартів, спрямовані на забезпечення високої якості розробок. Ці системи мають досить ефективні механізми реалізації законодавчих актів у галузі інформатизації, в основі яких лежать комерційний інтерес і приватна ініціатива.4.2. ОСНОВНІ ПОЛОЖЕННЯ БРИТАНСЬКОЇ ТЕХНОЛОГІЇ РОЗРОБКИ АВТОМАТИЗОВАНИХ СИСТЕМ SSADM4.2.1. Загальна характеристика технології SSADMТехнологія SSADM була задумана як уніфікована технологія створення систем, що вміщують досить складні бази даних. З метою забезпечення універсальності було вжито заходів щодо усунення залежності від галузі застосування АС, що розробля-ється, від програмного середовища і апаратних засобів. Усього цього автори технології SSADM досягли. Саме цьому вона інтен-сивно використовується для розробки досить широкого класу АС, серед яких є й системи реального часу. Універсальність технології SSADM має і зворотний бік — вона не охоплює всього життєвого циклу автоматизованих систем (рис. 4.1). З рисунка видно, що технологія застосовується після того, як визначено стратегію автоматизації, що має бути відображена в тактико-технічному завданні. Технологічний процес SSADM підтримує аналіз реалізованості запропонованого завдання, визначені вимоги до нової АС, а також її проектування. У свою чергу проектування поділяється на дві стадії — логічне й фізичне. При цьому логічне проектування передбачає прийняття технічних рішень безвідносно до середовища реалізації, тобто до системи програмування, ОС, СУБД і апаратури. На стадії фізичного проектування відбувається прив’язка логічного проектування до такого сере-довища.

Рис. 4.1. Місце технології SSАDM у життєвому циклі автоматизованої системиОсновні принципи технології SSADMРозробники технології SSADM виходили з таких принципів:1) постійного залучення представників майбутніх користу-вачів до процесу вироблення рішень протягом усього проекту-вання АС;2) чіткої структуризації технологічного процесу, взаємної ув’язки стадій, етапів і проектних процедур, явної регламентації ролей усіх учасників розробки;3) ефективного контролю за ходом розробки з боку керів-ників проекту, вбудованого контролю якості проектування на базі формалізованих критеріїв, можливості використання існую-чих технологій автоматизованого управління розробкою;4) ув’язування з технологіями, реалізованими в існуючих системах програмування та управління базами даних;5) формалізації процесу розробки, яка забезпечує широке використання засобів автоматизації проектування.Загалом у технології SSADM можна умовно виділити дві ос-новні складові частини: типовий технологічний процес і методичне забезпечення.4.2.2. Типовий технологічний процес SSADMНа рис. 4.1 показано типовий технологічних процес (ТПП), який складається з п’яти узагальнених стадій. У свою чергу ці стадії поділяються на сім дрібніших стадій, стадії — на етапи, а етапи — на операції. На рис. 4.2 зображено структурну схему ТПП. На ній, зокрема, наведено основні проектні документи, які розробляються на відповідних стадіях. Деякі документи, наприклад Каталог вимог і Логічна модель даних, є вихідними документами для деяких стадій. Це свідчить про ітераційний ха-рактер процесу вироблення проектних рішень у рамках техно-логії SSADM.Далі наведемо короткий опис робіт, що виконуються на кож-ній стадії.Стадія 0. Оцінювання реалізованості. Стадія необов’язкова, оскільки передбачені на ній роботи виконуються, як правило, при розробці стратегії автоматизації. Якщо проект досить складний, то на цій стадії розробляють загальний задум і оцінюють витрати і очікуваний ефект з урахуванням наявних ре-сурсів.Стадія 1. Передпроектне обстеження. Мета стадії — побудувати формалізовану модель існуючої системи або організації, виявити її недоліки і сформулювати основні вимоги до нової системи, які поки що в неформалізованому вигляді відобража¬ють у Каталозі вимог. Оцінюють важливість кожної виявленої вимоги (наприклад, за трибальною шкалою). Для моделювання використовують зображення існуючої системи у формі Схем інформаційних потоків (СІП). Дані, що обробляються, документують у вигляді логічної схеми даних (ЛСД).

Заявка (ТТЗ) на створення АС

Рис. 4.2. Узагальнена система типового технологічного процесу SSADM Стадія 2. Вибір варіанта автоматизації. Мета — розробити кілька можливих варіантів побудови нової системи і вибрати з них найкращий. Вимоги, зафіксовані на попередній стадії, проектувальники розбивають на кілька перехресних множин залежно від їх важливості і з урахуванням їх змісту. Для кожної також групи складають короткий опис варіанта побудови нової системи і дають якісну, а якщо можливо, і кількісну оцінку його вартості та ефективності. Наприклад, в одну групу можуть бути включені лише вимоги з найвищим пріоритетом, а в іншу — всі виявлені вимоги. Першій з них відповідає найдешевший варіант системи, що забезпечує реалізацію мінімального набору функ-цій, а другій — найдорожчий варіант з найбільш повними функ-ціональними можливостями. Ці два варіанти утворюють кордони, в межах яких слід з урахуванням обмежень на виділені ресурси шукати компромісне рішення. Для цього складають і оці¬нюють ще кілька проміжних варіантів, а для остаточного роз-гляду відбирають два-три найбільш прийнятних, для яких складають більш детальний опис і оцінки. Ці варіанти пред’являють замовникові і представникам майбутніх користувачів, які серед найкращих вибирають кінцевий варіант.Стадія 3. Розробка технічного завдання. Мета — складання досить повного формалізованого опису вимог до майбутньої системи згідно з варіантом, обраним на попередній стадії. На цій стадії розробляються формалізовані описи функціонального, предметного і динамічного аспектів концептуальної частини майбутньої АС. Одночасно формалізують вимоги до інтерфейсу користувача і розробляють його демонстраційний прототип, призначений для того, щоб оцінити, наскільки відповідають вимогам користувачів форми вхідної та вихідної інформації і структура діалогової взаємодії. Остаточно погоджені формалі-зовані вимоги збирають у комплект документів — технічне зав-дання. Основну його частину складають логічна модель даних (ЛМД), моделі функціональних задач (МФЗ), а також результати прототипування, що відображають найважливіші вимоги до інтерфейсу.Стадія 4. Вибір варіанта технічної реалізації. Мета — визначення найбільш прийнятного варіанта середовища програмної реалізації, а також складу і конфігурації технічних засобів. На основі відомостей, що містяться в технічному завданні, оціню¬ють потрібні продуктивність обчислювального пристрою і обсяг пам’яті, які необхідні для зберігання і обробки даних. Це дає змогу також конкретизувати вимоги до програмного середовища реалізації, звузити коло пошуку відповідних програмних засобів і систем. При цьому розробляють кілька можливих ва¬ріантів і кожний з них оцінюють виходячи з критерію вар¬тість/ефективність. З урахуванням усіх істотних чинників, що впливають на якість майбутньої системи, остаточно зупиняються на найбільш прийнятному варіанті.Стадія 5. Розробка логічного проекту. Мета — спроектувати комплекс програмних засобів на логічному рівні, тобто на незалежному від середовища реалізації. Ці проектні роботи виконуються одночасно зі стадією 4. На основі технічного завдання спочатку розробляють логіку діалогової взаємодії. Потім проектують алгоритми задач обробки даних, а також інформаційних задач. При цьому, якщо необхідно, уточнюють каталог вимог і логічну модель даних. Розроблені проектні документи погоджують між собою і об’єднують разом з ЛМД у логічний проект.Стадія 6. Фізичне проектування. Мета — згенерувати роботоздатний фізичний опис даних у вибраному середовищі реалізації і розробити завдання на створення програмних компо-нентів майбутньої АС. На базі існуючої логічної моделі даних розробляють первісний варіант її фізичного зображення і оцінюють його роботоздатність. У разі потреби, з метою прискорення доступу до деяких груп даних, доопрацьовують ЛМД, зокрема, добавивши класи індексних інформаційних об’єктів. У логічні постановки задач вносять елементи, які залежать від специфіки середовища реалізації, наприклад опису даних на вибраній мові програмування. При цьому уточнюють раніше отримані оцінки потрібної пам’яті та швидкодії обчислювальних засобів, і в разі потреби вносять корективи в проект. На закінчення уточнюють деталі реалізації інтерфейсу користувача і відображають їх у завданнях на програмування. Розроблені постановки задач збирають у єдиний пакет — фізичний проект.Отже, основним продуктом, створеним з використанням технології SSADM, є комплект документів, на основі яких розроблювана АС може бути реалізована на обчислювальному пристрої з використанням системи програмування і СУБД, вибра¬них на стадії 4.4.2.3. Основні проектні методикиМетодичне забезпечення технології SSADM утворене 13 методиками проектування АС, що тісно пов’язані між собою і з елементами ТПП. Їх коротку характеристику наведено в табл. 4.1.Методики значно відрізняються за ступенем формалізації проектних процедур, що в них містяться. Наприклад, методика «Реляційний аналіз даних» жорстко формальна і може бути цілком автоматизована. Щодо деяких інших, то вони важко піддаються автоматизації, однак їх автори доклали максимум зусиль для того, аби чітко структурувати проектні процедури і формалізувати критерії оцінки якості результатів. Прикладами таких методик є «Визначення вимог до АС» і «Вибір варіантів».

Таблиця 4.1КОРОТКА ХАРАКТЕРИСТИКА МЕТОДИК№ п/п Назва методики Характер основних проектних документів Номери стадій, на яких використовуються1 Визначення вимог до АС Каталог форм 0, 1, 2, 3, 4, 5, 62 Моделювання інформаційних потоків Схема, таблична форма 0, 1, 2, 3,3 Логічне моделювання даних Схема, таблична форма 0, 1, 2, 3, 4, 54 Визначення функціональних задач Схема, таблична форма 1, 2, 35 Динамічне моделювання да-них Схема, таблична форма 3, 56 Реляційний аналіз даних Таблична форма 1, 3, 57 Вибір варіантів автоматизації Пояснювальна записка, таблична форма, схема 28 Розробка демонстраційного прототипу Відеограма, схема 39 Вибір варіанта технічної реалізації Пояснювальна записка, таблична форма, схема 410 Проектування діалогової взаємодії Таблична форма, схема 3, 511 Логічне проектування процедур обробки даних Таблична форма, схема 512 Фізичне проектування баз даних Таблична форма, схема 613 Фізичне проектування процедур обробки даних Таблична форма, схема 6

З метою залучення користувачів до процесу розробки цілий ряд методик базується на інтенсивному використанні зображень проектних рішень у графічній формі, що забезпечує достатню наочність і не потребує для розуміння їх суті спеціальної підго-товки в галузі інформаційних технологій. Така форма, наприклад, лежить в основі методик «Моделювання інформаційних потоків», «Логічне моделювання даних», «Динамічне моделювання даних» та ін.У межах ТПП використання окремих методик, наприклад «Вибір варіантів», обмежено однією технологічною стадією або навіть етапом. Однак через ітераційний характер розробки основних проектних документів більшість методик використовуються протягом кількох стадій. Методичне забезпечення тех¬нології SSADM відрізняється від відомих аналогів тим, що значно підвищує якість проектування. Ідеться про поняття «подія», яке, поряд з поняттями «дані» і «задача», займає в SSADM центральне місце. Введення до розгляду поняття «подія» дозволяє перенести прийняття проектних рішень з цих питань на стадію 3 і зафіксувати їх у проектних документах у досить загальному вигляді й у формі, зрозумілій користувачам, які таким чином можуть контролювати правильність рішень на змістовому рівні.Крім того, якщо традиційні методи проектування зорієнто-вані на зображення проекту майбутньої системи лише в просторі «дані» — «задачі», то технологія SSADM дає змогу розглядати проект ще в двох інших проекціях: «дані» — «події» і «події» — «задачі». Наявність цих двох допоміжних аспектів дозволяє роз-робникам вже на ранніх стадіях виявити приховані суперечності в проекті та усунути помилки ще до того, як їх могли б знайти за традиційного підходу.Усі методики, що входять до складу технології SSADM, викладено досить детально, в доступній формі та забезпечено прикладами заповнення проектних документів.4.2.4. Перспективи розвитку технології SSADMЗа час, що минув з 1990 р., коли було введено в дію четверту версію технології SSADM, у галузі програмної інженерії відбу-лися деякі зміни:— набули поширення вдосконалені методи передпроектного обстеження організацій і раціоналізації їхньої діяльності;— були створені й стали широко використовуватись інстру-ментальні програмні засоби для розробки графічного інтер¬фейсу користувача, а також засоби для швидкого прототипування додатків;— більш високого ступеня зрілості досягли об’єктно-орієнто-вані методи розробки автоматизованих систем.Усі ці нововведення, що потенційно дають змогу значно підвищити якість і продуктивність праці розробників АС, не знайшли свого відображення в четвертій версії SSADM; саме тому в середині 1995 р. було запроваджено вдосконалену версію 4.2. Ця версія була доповнена методикою, яка підтримує оціню-вання реалізованості та передпроектне обстеження, а також вмі-щує конкретні рекомендації розробникам щодо виявлення вузьких місць в існуючій системі та складання каталогу вимог. Окрім того, дещо змінився ТПП. Зокрема, розробка форм вхідних і ви¬хідних документів і процедур діалогу була повністю винесена на стадію 3 (у версії 4 логіку діалогів проектують на стадії 5, а деталі їх реалізації — на стадії 6). Це нововведення дало змогу ширше використовувати засоби проектування графічного інтер¬фейсу, а також зменшити кількість розроблюваних документів, прискоривши при цьому розробку АС.4.3. ОЦІНКА БЕЗПЕКИ ІНФОРМАЦІЙНИХ СИСТЕМДля оцінки реального стану безпеки інформаційної системи застосовуються різні критерії. Аналіз вітчизняного і зарубіжного досвіду показав певну спорідненість підходу до визначення стану безпеки в різних країнах. Її суть така. Для того щоб користувач міг оцінити безпеку, запроваджено деяку систему показників і задано ієрархію класів безпеки. Кожному класу відповідає певна сукупність обов’язкових функцій. Ступінь реалізації вибраних критеріїв показує поточний стан безпеки. Подальші дії зводяться до порівняння реальних загроз із реальним станом безпеки. Якщо реальний стан повною мірою перекриває загрози, система безпеки вважається надійною і не потребує додаткових заходів. Таку систему можна віднести до класу систем з повним перекриттям загроз і каналів витікання інформації. У протилежному разі система безпеки потребує додаткових засобів захисту.4.3.1. Вимоги до безпеки інформаційних систем у СШАПитаннями стандартизації і розробки нормативних вимог на захист інформації в США займається Національний центр комп’ю¬терної безпеки Міністерства оборони США (NCSC). Цей центр у 1983 р. видав критерії оцінки безпеки комп’ютерних систем (ТСSEC). Досить часто цей документ називають «оранжевою книгою». Затверджена як урядовий стандарт, вона вміщує основні вимоги і специфікує класи для оцінки рівня безпеки комп’ютерних систем. У цій книзі наведено такі рівні безпеки систем: вищий клас — А; проміжний клас — В; нижчий рівень безпеки — С; клас систем, що не пройшли випробування, — D.До класу D віднесено такі системи, які не пройшли випробу-вання на більш високий рівень захищеності, а також системи, які використовують для захисту лише окремі заходи або функції (підсистеми) безпеки.Клас С1: вибірковий захист. Засоби безпеки систем класу С1 повинні задовольняти вимоги вибіркового керування доступом, забезпечуючи розділення користувачів і даних. Для кожного об’єкта і суб’єкта задається перелік допустимих типів доступу (читання, запис, друкування і т.ін.) суб’єкта до об’єкта. У системах цього класу обов’язковою є ідентифікація і аутентифікація суб’єкта доступу, а також підтримка з боку обладнання.Клас С2: керований доступ. До вимог класу С2 додаються вимоги унікальної ідентифікації суб’єкта доступу, захисту за замовчуванням і реєстрації подій. Унікальна ідентифікація означає, що будь-який користувач системи повинен мати унікальне ім’я. Захист за замовчуванням передбачає призначення повноважень доступу користувачам за принципом «усе, що не дозволено, заборонено», тобто всі ті ресурси, що явно не дозволені користувачеві, розглядаються як недоступні. У системах цього класу обов’язко¬вим є ведення системного журналу, в якому повинні відмічатися події, пов’язані з безпекою системи.У системах класу В має бути цілком контрольований доступ. Кожний суб’єкт і об’єкт системи забезпечуються мітками (або рівнями) конфіденційності й рішення щодо доступу суб’єкта до об’єкта приймається за заздалегідь визначеним правилом на базі зіставлення інформації обох міток.Клас В1: міточний захист. Мітки безпеки мають бути присвоєні всім суб’єктам системи, які можуть містити конфіденційну інформацію. Доступ до об’єктів дозволяється в тому разі, якщо мітка суб’єкта задовольняє певний критерій відносно мітки об’єкта.Клас В2: структурований захист. У цьому класі додатково до вимог класу В1 додаються вимоги наявності добре визначеної і задокументованої формальної моделі політики безпеки, яка по-требує дії вибіркового і повноважного керування доступом до всіх об’єктів системи. Вимоги керування інформаційними потоками вводяться згідно з політикою безпеки. (Політика безпеки — це набір законів, правил і практичного досвіду, на основі яких будуються управління, захист і розподіл конфіденційної інформації).Клас В3: області безпеки. У системах цього класу визнача-ються області безпеки, які будуються за ієрархічною структурою і захищені одна від одної за допомогою спеціальних механізмів. Усі взаємодії суб’єктів із об’єктами жорстко контролюються спеціальним монітором. Система контролю повідомляє адміні-стратора безпеки і користувача про порушення безпеки.Клас А1: верифікація. Системи цього класу відрізняються від класу В3 тим, що для перевірки специфікацій застосовуються методи формальної верифікації — аналізу специфікацій системи на предмет неповноти або суперечності, що може призвести до появи проривів у безпеці.Аналіз класів захищеності показує, що чим він вищий, тим більш жорсткі вимоги висуваються до системи.

5. МІЖНАРОДНИЙ ЕЛЕКТРОННИЙ ОБМІНКОМЕРЦІЙНИМИ І ФІНАНСОВИМИ ДАНИМИ

5.1. ПРИНЦИПИ ЕЛЕКТРОННОГО ОБМІНУТрадиційна паперова документація, методи її обробки і пересилання за допомогою звичайної пошти пов’язані зі значними виробничими та комерційними витратами. Експерти оцінюють вартість обробки і ведення паперової документації у 3,5–7,0 % загальної вартості комерційних операцій і доставки товарів [18, с. 5]. Виграш від застосування електронного обміну даними (ЕОД), наприклад, у автомобільній промисловості США оціню¬ється більш як у 200 дол. на один виготовлений автомобіль [18, с. 7].На рис. 5.1 показано загальну традиційну схему поставки то-вару, яка включає 11 операцій: 1 — запит ціни, умов поставки (по телефону або лист-запит); 2 — контрактна пропозиція, котировка на біржі (по пошті); 3 — видача замовлення; 4 —орга-нізація постачальником внутрішніх замовлень; 5 — підготовка відомості комплектування; 6 — комплектування та пакування; 7 — відправка товару; 8 — повідомлення про поставку; 9 — виставляння фактур-накладних; 10 — виставляння рахунку; 11 — оплата.З цієї схеми видно, що постачальник і замовник у процесі своєї взаємодії обмінюються запитами повідомленнями, торговими і постачальницькими документами, фінансовими рахунками та квитанціями. Цілком ясно, що електронний обмін документами має великі переваги щодо оперативності, достовірності та надійності обміну.Електронний обмін даними — це міжкомп’ютерний обмін ді-ловими, комерційними та фінансовими електронними документами, наприклад замовленнями, платіжними інструкціями, контрактними пропозиціями, накладними, квитанціями.ЕОД забезпечує оперативну взаємодію торгових партнерів (клієнтів, постачальників, торгових посередників, експедиторів та ін.) на всіх етапах підготовки торгової угоди, укладання контракту і реалізації поставки.ЕОД для комерційних цілей (ЕОКД) на етапі оплати контракту і переказу коштів може взаємодіяти із службою електронного обміну фінансовими документами (ЕОФД). Така взаємодія ЕОКД і ЕОФД створює для покупців (клієнтів) ефективне середовище при виконанні всіх торгово-платіжних операцій:— он-лайн — перегляд каталогів торгових пропозицій, товарів і послуг на ринку;— вибір у інтерактивному режимі потрібного товару/послу-ги, уточнення умов (вартості й термінів поставки, торгових знижок, гарантійних і сервісних зобов’язань);— он-лайн замовлення товару/послуги або запит контрактної пропозиції, погодження та укладання контракту;— оперативний контроль поставки товару;— одержання за допомогою електронної пошти супровідних документів (накладних, фактур, комплектуючих відомостей то-що);— підтвердження завершення поставки товару/послуги, виставляння і оплата рахунків;— виконання банківсько-кредитних і платіжних операцій.

Фаза Замовник (клієнт) Постачальник Пояснення1 Запит ціни і умовпоставки Лист-запит або телефон-ні переговори 2 Контрактна пропозиція Лист-запит або телефон¬ні переговори3 Видача замовлення Лист-запит або форма замовлення (можливо, в комп’ютерному вигляді)4 Видача внутрішніхзамовлень Внутрішня технологія5 Підготовка відомості комплектування Внутрішня технологія6 Комплектування і пакування 7 Відправка товару 8 Повідомлення про постав-ку Комп’ютерна форма9 Виставляння фактурнакладних Комп’ютена форма10 Виставляння рахунку Комп’ютерна форма11 Оплата Рис. 5.1. Загальна схема замовлення і поставки товаруДля реалізації цих операцій користувачі служби ЕОД повинні використовувати термінальні станції, модеми або адаптери стандарту Х.25, від¬повідні телекомунікаційні програми.Для забезпечення надійної передачі великих обсягів даних необхідні виділені лінії зв’язку, програмне забезпечення передачі файлів, електронної пошти і підключення до мережі Х.25. Потрібні також засоби захисту даних від несанкціонованого доступу.Історія виникнення і розвитку ЕОД веде свій відлік від початку 80-х років, коли несумісність окремих фірмових технологій обробки комерційних даних не дозволяла інтегрувати їх у єдину систему, яка б забезпечила комплексну механізацію міжнародних торгових операцій.У 1983–1985 рр. міжнародні організації ООН (UN/ECE i ІSO) почали розробку процедур, форматів даних і міжнародних кодових систем для ЕОД. Було створено міжнародну робочу групу UN/ECE, яка в жовтні 1988 р. розробила першу версію міжна¬родного стандарту United Nations Eleсtronic Data Interсhange for Admistration, Commerce and Transport — UN/EDIFACT. (ООН/Електронний обмін даними для адміністрації, торгівлі й транспорту).У EDIFACT було виділено чотири основних компоненти, які підлягають стандартизації при підготовці документів для пере-дачі по каналах телекомунікацій. Це елементи даних (data elements), стандартні групи елементів даних (standart data segments), стандартні повідомлення (standart messages) і правила створення форматів документів (syntax rules).Отже, було розроблено набір синтаксичних правил і ко-мерційних елементів, який дістав скорочену назву EDIFACT і був оформлений у вигляді двох стандартів ISO:ISO 7372 — Trade Data Element Directory (Довідник ко-мерційних елементів даних);ISO 9735 — EDIFACT — Appliсаtion Level Syntaх rules (Пра-вила синтаксису на користувацькому рівні).Стандарти EDIFACT розроблялися для використання в глобальних комп’ютерних мережах з широким колом користу-вачів: державними установами, виробниками товарів, виробів і послуг, дистриб’юторами, брокерами, транспортними експедиторами, банками, страховими компаніями та ін.Головні цілі створення та використання EDIFACT такі:— визначення стандартних за синтаксисом і семантикою повідомлень, які відповідають міжнародним стандартам;— заміна звичайних паперових форм і документів електрон-ними документами та відповідними методами їх обробки;— прискорення документообігу і відповідно оперативності обробки комерційних і фінансових транзакцій;— створення для малих, середніх і великих фірм більш сприятливих і рівних умов ринкової конкуренції;— поліпшення умов для підготовки і здійснення торгових угод;— більш широке й масове використання клієнтами сучасних комп’ю¬терних мереж і їх послуг.На базі стандарту EDIFACT у 1987–1990 рр. інтенсивно розвивається інфраструктура електронного обміну даними. Процес обміну електронними документами підтримується різними комп’ютерними і комунікаційними технологіями, до яких входять:— комп’ютерні робочі станції для підготовки електронних документів, контролю вхідних даних і виходу на мережі передачі даних;— бази даних, які містять комерційні та фінансові дані, котировки, класифікатори продукції, дані про постачальників і ринки;— інтерактивні інформаційні системи (системи обробки замовлень, біржові інформаційні служби, банки даних, відеотекс тощо);— електронна пошта, системи обробки повідомлень, галузеві та проблемно-орієнтовані системи EDIFACT, системи обміну фінансовими документами.Інформаційні та телекомунікаційні системи забезпечують для своїх користувачів комплекс послуг з обробки й видачі довід-кових даних, комерційних звітів, замовлень і торгових пропо-зицій, рахунків і платіжних квитанцій.Усі ці послуги надаються як прикладні служби (Value additional Services), що створюються технологіями електронного обміну даними. На сучасному етапі розрізнюють такі основні види прикладних служб.1. Он-лайнові бази даних (ОЛБД), які доступні в оперативному режимі з терміналів користувачів; он-лайнові БД ціло¬добово відкриті для діалогового пошуку інформації та видачі довідок і різних статистичних звітів; користувачами ОЛБД можуть бути спеціалісти комерційних і фінансових організацій, економісти, ділери, постачальники, агенти фінансових і торгових організацій.2. Електронна пошта (EP — Electronic Post) — система обмі-ну і обробки повідомлень (сукупність електронних поштових скриньок, програмних засобів обробки, зберігання та передачі повідомлень, термінальних станцій для підготовки і введення повідомлень). Користувачі ЕП можуть проводити міжперсо-нальний обмін повідомленнями, розсилати їх за списками адрес, затребувати свої повідомлення з поштових скриньок, органі-зовувати проблемні телеконференції і виконувати інші функції обробки повідомлень (електронних документів).3. Електронна передача коштів (EFT — Electronic Funds Transfer). Система передачі фінансових (кредитних, платіжних) документів між клієнтами і банками, між банками, між банками та іншими фінансовими і комерційними організаціями. Міжна-родна мережа обміну фінансовою інформацією SWIFT забезпечує багато функцій EFT.4. Електронний обмін даними (EDI — Electronic Data Inter-сhange). Багатоцільова система обміну документами, які мають розвинену структуру даних. Як правило, реалізується на базі стандартних програмних і технічних засобів електронної пошти.5. Управляючі мережні служби (Managed Network Services). Виконують різні виробничі, адміністративні й службові функції управління об’єктами, технологічними лініями, транспортними системами і працівниками підприємств. Реалізуються на базі внутрішньофірмових мереж ЕОМ, розподілених між підрозді-лами фірми.6. Телеметричні служби. Система оперативного спостережен-ня, дистанційного вимірювання та контролю за нерухомими і рухомими об’єктами.Бізнесмени, торгові агенти, працівники транспорту, банків-ські спеціалісти, адміністратори, економісти і бухгалтери здебіль¬шого використовують перші чотири служби ЕОД (ОЛБД, ЕР, EFT, ЕDІ). При цьому важливе значення мають вимоги інтег-ральності послуг, єдиного мережного доступу (тобто підклю-чення до комп’ютерних мереж за допомогою одного терміналу або ПЕОМ), максимально можливої надійності, простоти й ком-фортності процедур підготовки електронних документів і їх телекомунікаційної обробки. Служби ЕОД повинні бути доступні через загальнодоступні телефонні мережі або мережі передачі даних на базі стандарту Х.25.На сучасному етапі ЕОД діє або впроваджується практично в усіх країнах.Міжнародний статус стандарту EDIFACT передбачає його обов’язкове використання при адекватному обміні даними із зарубіжними партнерами для всіх підприємств і організацій Ук-раїни, які здійснюють зовнішньоеко¬номічну діяльність.Для широкого впровадження ЕОД в Україні необхідно організувати:— освоєння світової практики ЕОД, активне залучення українських спеціалістів до роботи в міжнародних організаціях, прийняття вітчизняних програм розвитку ЕОД;— публікацію стандартів ІSO, UN/EDIFACT та ін., проведення навчальних курсів і вивчення зарубіжних систем ЕОД;— роботи по створенню базових телекомунікаційних служб (Х.400, он-лайнові бази даних);— координацію проектів з уніфікації торгових і фінансових процедур, стандартизації форм документів, елементів даних, найменувань організацій;— сполучення вітчизняних систем ЕОД з міжнародними і зарубіжними фірмовими службами, створення пунктів доступу та шлюзових станцій для взаємообміну електронними документами із зарубіжними партнерами.5.2. СТРУКТУРА ДАНИХ EDIFACT. ЗАГАЛЬНІ СИНТАКСИЧНІ ПРАВИЛА (СТАНДАРТ ІSO 9735)Повідомлення EDIFACT належать до прикладного (7-го) рівня еталонної моделі OSI/ІSO. Усі повідомлення мають уніфікова¬ний формат, який стандартно регламентує розміщення управляючих полів і спеціальних знаків, сегментів даних, складені й прості значення елементів даних.У структурі повідомлень EDIFACT визначено такі загальні синтаксичні правила:а) два рівня кодування повідомлень: рівень А — 7-бітовий код відповід¬но до ISO 646; рівень В — 8-бітовий код відповідно до ISO 8859 або ISO 6937;б) управляючий сегмент даних UNA є ідентифікатором початку кожного блоку повідомлень. Сегмент UNA визначає також типи використовуваних у цьому блоці розподільників (управляючих знаків) і їх функціональне значення;в) другим за UNA йде UNB — кореневий сегмент данихкористувача. У цьому сегменті вказується версія формату EDIFACT, організація, яка відповідає за її супроводження. Крім того, у сегменті UNB визначаються джерело та отримувач пові-домлень, дата й час передачі повідомлень, дата погодження паролей та інша службова інформація;г) кожний набір (пакет) повідомлень користувача (набір фінансових, комерційних або адміністративних документів) починається з третього сегмента UNG. Сегмент UNG є обов’яз-ковим і вміщує інформацію про всі наступні повідомлення: дже-рело і отримувач набору повідомлень, класифікаційні індекси повідомлень та ін.;д) кожне окреме повідомлення (документ) починається із сег-мента UNH, який є заголовком повідомлення. Заголовок пові-домлення містить його посилковий номер, тип повідомлення, номер версії або редакції;е) кожне повідомлення закінчується сегментом UNT — ідентифіка¬тором кінця повідомлення; в сегменті UNT наводиться інформація про кіль¬кість сегментів у даному повідомленні, посилковий номер повідомлення;є) набір повідомлень закінчується сегментом UNE, в якому вказується кількість повідомлень, посилковий номер набору повідомлень;ж) блок повідомлень закінчується сегментом UNZ, у якому вказується кількість повідомлень або наборів повідомлень.На рис. 5.2 показано загальну ієрархію повідомлень і струк-турних елементів EDIFACT.

Рис. 5.2. Ієрархічна структура повідомлень ЕDIFACTРозподільники, які визначаються в сегменті UNA, можуть мати, наприклад, такий вигляд (табл. 5.1).Таблиця 5.1Позиція сегмента UNA Тип розподільника Розподільник1 Розподільник компонентів елементів даних :2 Розподільник елементів даних +3 Десяткова крапка .4 Індикатор відміни синтаксису ?5 Резерв для майбутнього використання 6 Розподільник сегментів ,

Сторінки


В нашій електронній бібліотеці ви можете безкоштовно і без реєстрації прочитати «Інформаційні системи в міжнародному бізнесі» автора Гужва В. на телефоні, Android, iPhone, iPads. Зараз ви знаходитесь в розділі „читати“ на сторінці 2. Приємного читання.

Запит на курсову/дипломну

Шукаєте де можна замовити написання дипломної/курсової роботи? Зробіть запит та ми оцінимо вартість і строки виконання роботи.

Введіть ваш номер телефону для зв'язку, в форматі 0505554433
Введіть тут тему своєї роботи