Агресивний маркетинг

Етапи проектування

На першому етапі основним підходом у проектуванні ІС був метод "нагору", коли система створювався як набір додатків, найбільш важливих у цей момент для підтримки діяльності підприємства. Основною метою цих проектів було не створення продуктів, що тиражуються, а обслуговування поточних потреб конкретної установи. Такий підхід почасти зберігається й сьогодні. У рамках "клаптевої автоматизації" досить добре забезпечується підтримка окремих функцій, але практично повністю відсутня стратегія розвитку комплексної системи автоматизації, а об'єднання функціональних підсистем перетворюється в самостійну й досить складну проблему.

Створюючи свої відділи й управління автоматизації, підприємства намагалися "облаштуватися" самотужки. Однак періодичні зміни технологій роботи й посадових інструкцій, складності, пов'язані з різними поданнями користувачів про тих самих дані, приводили до безперервних доробок програмних продуктів для задоволення всі нових і нових побажань окремих працівників. Як наслідок - і робота програмістів, і створювані ІС викликали невдоволення керівників і користувачів системи.

Наступний етап пов'язаний з усвідомленням того факту, що існує потреба в досить стандартних програмних засобах автоматизації діяльності різних установ і підприємств. Із усього спектра проблем розроблювачі виділили найбільш помітні: автоматизацію ведення бухгалтерського аналітичного обліку й технологічних процесів. Системи почали проектуватися "униз", тобто в припущенні, що одна програма повинна задовольняти потреби багатьох користувачів.

Сама ідея використання універсальної програми накладає істотні обмеження на можливості розроблювачів по формуванню структури бази даних, екранних форм, на вибір алгоритмів розрахунку. Закладені "зверху" тверді рамки не дають можливості гнучко адаптувати систему до специфіки діяльності конкретного підприємства: урахувати необхідну глибину аналітичного й виробничо-технологічного обліку, включити необхідні процедури обробки даних, забезпечити інтерфейс кожного робочого місця з урахуванням функцій і технології роботи конкретного користувача. Рішення цих завдань вимагає серйозних доробок системи. Таким чином, матеріальні й тимчасові витрати на впровадження системи і її доведення під вимоги замовника звичайно значно перевищують заплановані показники.

Згідно статистичним даним, зібраним Standish Group (США), з 8380 проектів, обстежених у США в 1994 році, невдалими виявилися більше 30% проектів, загальна вартість яких перевищувала 80 мільярдів доларів. При цьому виявилися виконаними в строк лише 16% від загального числа проектів, а перевитрата коштів склав 189% від запланованого бюджету.

У той же час, замовники ІС стали висувати усе більше вимог, спрямованих на забезпечення можливості комплексного використання корпоративних даних у керуванні й плануванні своєї діяльності.

Таким чином, виникла нагальна потреба формування нової методології побудови інформаційних систем.

Ціль такої методології полягає в регламентації процесу проектування ІС і забезпеченні керування цим процесом для того, щоб гарантувати виконання вимог як до самої ІС, так і до характеристик процесу розробки.

3.2.1. Основні завдання методологій проектування ІС

Основними завданнями, рішенню яких повинна сприяти методологія проектування корпоративних ІС, є наступні:

забезпечувати створення корпоративних ІС, що відповідають цілям і завданням організації, а також пропонованим вимогам по автоматизації ділових процесів замовника;

гарантувати створення системи із заданою якістю в заданий термін й у рамках установленого бюджету проекту;

підтримувати зручну дисципліну супроводу, модифікації й нарощування системи;

забезпечувати наступність розробки, тобто використання в розроблювальної ІС існуючої інформаційної інфраструктури організації (зачепила в області інформаційних технологій).

Впровадження методології повинне приводити до зниження складності процесу створення ІС за рахунок повного й точного опису цього процесу, а також застосування сучасних методів і технологій створення ІС на всьому життєвому циклі ІС - від задуму до реалізації.

Проектування ІС охоплює три основні області:

проектування об'єктів даних, які будуть реалізовані в базі даних;

проектування програм, екранних форм, звітів, які будуть забезпечувати виконання запитів до даних;

облік конкретного середовища або технології, а саме: топології мережі, конфігурації апаратних засобів, використовуваної архітектури (файл-сервер або клієнт-сервер), паралельної обробки, розподіленої обробки даних і т.п.

Проектування інформаційних систем завжди починається з визначення мети проекту. У загальному виді мета проекту можна визначити як рішення ряду взаємозалежних завдань, що включають у себе забезпечення на момент запуску системи й протягом усього часу її експлуатації:

необхідної функціональності системи й рівня її адаптивності до умов, що змінюються, функціонування;

необхідної пропускної здатності системи;

необхідного часу реакції системи на запит;

безвідмовної роботи системи;

необхідного рівня безпеки;

простоти експлуатації й підтримки системи.

Відповідно до сучасної методології, процес створення ІС являє собою процес побудови й послідовного перетворення ряду погоджених моделей на всіх етапах життєвого циклу (ЖЦ) ІС. На кожному етапі ЖЦ створюються специфічні для нього моделі - організації, вимог до ІС, проекту ІС, вимог до додатків і т.д. Моделі формуються робочими групами команди проекту, зберігаються й накопичуються в репозіторії проекту. Створення моделей, їхній контроль, перетворення й надання в колективне користування здійснюється з використанням спеціальних програмних інструментів - CASE-засобів.

3.2.2. Процес створення ІС

Процес створення ІС ділиться на ряд етапів (стадій [1]), обмежених деякими тимчасовими рамками й увінчуються випуском конкретного продукту (моделей, програмних продуктів, документації й ін.).

Звичайно виділяють наступні етапи створення ІС: формування вимог до системи, проектування, реалізація, тестування, запровадження в дію, експлуатація й супровід.

Початковим етапом процесу створення ІС є моделювання бізнес-процесів, що протікають в організації й реалізуючі її мети й завдання. Модель організації, описана в термінах бізнес-процесів і бізнес-функцій, дозволяє сформулювати основні вимоги до ІС. Це фундаментальне положення методології забезпечує об'єктивність у виробленні вимог до проектування системи. Безліч моделей опису вимог до ІС потім перетвориться в систему моделей, що описують концептуальний проект ІС. Формуються моделі архітектури ІС, вимог до програмного забезпечення (ПЗ) і інформаційному забезпеченню (ІЗ). Потім формується архітектура ПЗ й ІЗ, виділяються корпоративні БД й окремі додатки, формуються моделі вимог до додатків і проводиться їхня розробка, тестування й інтеграція.

Метою початкових етапів створення ІС, виконуваних на стадії аналізу діяльності організації, є формування вимог до ІС, коректно й точно, що відбиває мети, і завдання організації-замовника. Щоб специфікувати процес створення ІС, що відповідає потребам організації, потрібно з'ясувати й чітко сформулювати, у чому полягають ці потреби. Для цього необхідно визначити вимоги замовників до ІС і відобразити їх мовою моделей у вимоги до розробки проекту ІС так, щоб забезпечити відповідність цілям і завданням організації.

Завдання формування вимог до ІС є однієї з найбільш відповідальних, що важко формалізуються і найбільш дорогих і важких для виправлення у випадку помилки. Сучасні інструментальні засоби й програмні продукти дозволяють досить швидко створювати ІС по готових вимогах. Але найчастіше ці системи не задовольняють замовників, вимагають численних доробок, що приводить до різкого подорожчання фактичної вартості ІС. Основною причиною такого положення є неправильне, неточне або неповне визначення вимог до ІС на етапі аналізу.

На етапі проектування насамперед формуються моделі даних. Проектувальники як вихідна інформація одержують результати аналізу. Побудова логічної й фізичної моделей даних є основною частиною проектування бази даних. Отримана в процесі аналізу інформаційна модель спочатку перетвориться в логічну, а потім у фізичну модель даних.

Паралельно із проектуванням схеми бази даних виконується проектування процесів, щоб одержати специфікації (опису) всіх модулів ІС. Обоє ці процесу проектування тісно зв'язані, оскільки частина бізнесу-логіки звичайно реалізується в базі даних (обмеження, тригери, збережені процедури). Головна мета проектування процесів полягає у відображенні функцій, отриманих на етапі аналізу, у модулі інформаційної системи. При проектуванні модулів визначають інтерфейси програм: розмітку меню, вид вікон, гарячі клавіші й пов'язані з ними виклики.

Кінцевими продуктами етапу проектування є:

схема бази даних (на підставі ER-моделі, розробленої на етапі аналізу);

набір специфікацій модулів системи (вони будуються на базі моделей функцій).

3.2.3. Архітектури ІС

Крім того, на етапі проектування здійснюється також розробка архітектури ІС, що включає в себе вибір платформи (платформ) і операційної системи (операційних систем). У неоднорідної ІС можуть працювати кілька комп'ютерів на різних апаратних платформах і під керуванням різних операційних систем. Крім вибору платформи, на етапі проектування визначаються наступні характеристики архітектури:

Архітектура: "файл-сервер" або "клієнт-сервер";

Трирівнева архітектура з наступними шарами: сервер, ПО проміжного шару (сервер додатків), клієнтське ПО;

База даних: централізована або розподілена. Якщо база даних буде розподіленою, то які механізми підтримки погодженості й актуальності даних будуть використатися;

База даних: однорідні, тобто, чи будуть всі сервери баз даних продуктами того самого виробника (наприклад, всі сервери тільки Oracle або всі сервери тільки DB2 UDB). Якщо база даних не буде однорідної, то яке ПО буде використано для обміну даними між СУБД різних виробників (уже існуюча або розроблене спеціально як частина проекту);

чи будуть для досягнення належної продуктивності використатися паралельні сервери баз даних (наприклад, Oracle Parallel Server, DB2 UDB і т.п.).

Етап проектування завершується розробкою технічного проекту ІС.

На етапі реалізації здійснюється створення програмного забезпечення системи, установка технічних засобів, розробка експлуатаційної документації.

Етап тестування звичайно виявляється розподіленим у часі.

Після завершення розробки окремого модуля системи виконують автономний тест, що переслідує дві основні цілі: виявлення відмов модуля (твердих збоїв); відповідність модуля специфікації (наявність всіх необхідних функцій, відсутність зайвих функцій).

Після того як автономний тест успішно пройде, модуль включається до складу розробленої частини системи й група згенерованих модулів проходить тести зв'язків, які повинні відстежити їхній взаємний вплив.

Далі група модулів тестується на надійність роботи, весь комплект модулів проходить системний тест - тест внутрішнього приймання продукту, що показує рівень його якості. Останній тест інформаційної системи - приймально-здавальні випробування. Такий тест передбачає показ інформаційної системи замовникові й повинен містити групу тестів, що моделюють реальні бізнес-процеси, щоб показати відповідність реалізації вимогам замовника.

Необхідність контролювати процес створення ІС, гарантувати досягнення цілей розробки й дотримання різних обмежень (бюджетних, тимчасових й ін.) привело до широкого використання в цій сфері методів і засобів програмної інженерії: структурного аналізу, об’єктно-орієнтованого моделювання, CASE-систем.

Стандарти

Існує цілий ряд стандартів, що регламентують ЖЦ ПЗ, а в деяких випадках і процеси розробки.

Значний внесок у теорію проектування й розробки інформаційних систем внесла компанія IBM, запропонувавши ще в середині 1970-х років методологію BSP (Business System Planning - методологія організаційного планування). Метод структурування інформації з використанням матриць перетинання бізнес-процесів, функціональних підрозділів, функцій систем обробки даних (інформаційних систем), інформаційних об'єктів, документів і баз даних, запропонований в BSP, використається сьогодні не тільки в ІТ - проектах, але й проектах по реінжинірингу бізнес-процесів, зміні організаційної структури. Найважливіші кроки процесу BSP, їхня послідовність (одержати підтримку вищого керівництва, визначити процеси підприємства, визначити класи даних, провести інтерв'ю, обробити й організувати дані інтерв'ю) можна зустріти практично у всіх формальних методиках, а також у проектах, реалізованих на практиці.

Серед найбільш відомих стандартів можна виділити наступні:

ДЕРЖСТАНДАРТ 34.601-90 - поширюється на автоматизовані системи й установлює стадії й етапи їхнього створення. Крім того, у стандарті втримується опис змісту робіт на кожному етапі. Стадії й етапи роботи, закріплені в стандарті, більшою мірою відповідають каскадній моделі життєвого циклу [4].

ISO/IEC 12207:1995 - стандарт на процеси й організацію життєвого циклу. Поширюється на всі види замовленого ПО. Стандарт не містить опису фаз, стадій й етапів [5].

Custom Development Method (методика Oracle) по розробці прикладних інформаційних систем - технологічний матеріал, деталізований до рівня заготівель проектних документів, розрахованих на використання в проектах із застосуванням Oracle. Застосовується CDM для класичної моделі ЖЦ (передбачені всі роботи/завдання й етапи), а також для технологій "швидкої розробки" (Fast Track) або "полегшеного підходу", що рекомендують у випадку малих проектів.

Rational Unified Process (RUP) пропонує ітеративну модель розробки, що включає чотири фази: початок, дослідження, побудова й впровадження. Кожна фаза може бути розбита на етапи (ітерації), у результаті яких випускається версія для внутрішнього або зовнішнього використання. Проходження через чотири основні фази називається циклом розробки, кожен цикл завершується генерацією версії системи. Якщо після цього робота над проектом не припиняється, то отриманий продукт продовжує розвиватися й знову мине ті ж фази. Суть роботи в рамках RUP - це створення й супровід моделей на базі UML [6].

Microsoft Solution Framework (MSF) подібна з RUP, так само включає чотири фази: аналіз, проектування, розробка, стабілізація, є ітераційної, припускає використання об’єктно - орієнтованого моделювання. MSF у порівнянні з RUP більшою мірою орієнтована на розробку бізнес-додатків.

Extreme Programming (XP). Екстремальне програмування (сама нова серед розглянутих методологій) сформувалося в 1996 році. В основі методології командна робота, ефективна комунікація між замовником і виконавцем протягом усього проекту по розробці ІС, а розробка ведеться з використанням прототипів, що допрацьовують послідовно.

3.3.1. Стандарт ISO/IEC 12207

Відповідно до базового міжнародного стандарту ISO/IEC 12207 всі процеси ЖЦ ПО діляться на три групи:

1. Основні процеси:

придбання;

поставка;

розробка;

експлуатація;

супровід.

2. Допоміжні процеси:

документування;

керування конфігурацією;

забезпечення якості;

дозвіл проблем;

аудит;

атестація;

спільна оцінка;

верифікація.

Організаційні процеси:

створення інфраструктури;

керування;

навчання;

удосконалення.

У таблиці 3.1. наведені орієнтовні описи основних процесів ЖЦ. Допоміжні процеси призначені для підтримки виконання основних процесів, забезпечення якості проекту, організації верифікації, перевірки й тестування ПО. Організаційні процеси визначають дії й завдання, виконувані як замовником, так і розроблювачем проекту для керування своїми процесами.

Для підтримки практичного застосування стандарту ISO/IEC 12207 розроблений ряд технологічних документів: Керівництво для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) і Посібник із застосування ISO/IEC 12207 до керування проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management).

Таблиця 3.1. Зміст основних процесів ЖЦ ПО ІС (ISO/IEC 12207)

Пізніше був розроблений й в 2002 р. опублікований стандарт на процеси життєвого циклу систем (ISO/IEC 15288 System life cycle processes). До розробки стандарту були притягнуті фахівці різних областей: системної інженерії, програмування, керування якістю, людськими ресурсами, безпекою й ін. Був врахований практичний досвід створення систем в урядових, комерційних, військових й академічних організаціях. Стандарт застосуємо для широкого класу систем, але його основне призначення - підтримка створення комп'ютеризованих систем.

Відповідно до стандарту ISO/IEC серії 15288 [7] у структуру ЖЦ варто включати наступні групи процесів:

1. Договірні процеси:

придбання (внутрішні рішення або рішення зовнішнього постачальника);

поставка (внутрішні рішення або рішення зовнішнього постачальника).

2. Процеси підприємства:

керування навколишнім середовищем підприємства;

інвестиційне керування;

керування ЖЦ ІС;

керування ресурсами;

керування якістю.

3. Проектні процеси:

планування проекту;

оцінка проекту;

контроль проекту;

керування ризиками;

керування конфігурацією;

керування інформаційними потоками;

прийняття рішень.

4. Технічні процеси:

визначення вимог;

аналіз вимог;

розробка архітектури;

впровадження;

інтеграція;

верифікація;

перехід;

атестація;

експлуатація;

супровід;

утилізація.

5. Спеціальні процеси:

визначення й установка взаємозв'язків виходячи із завдань і цілей.

Стадії створення системи, передбачені в стандарті ISO/IEC 15288, трохи відрізняються від розглянутих вище. Перелік стадій й основні результати, які повинні бути досягнуті до моменту їхнього завершення, наведені в таблиці 2.2.

Таблиця 3.2. Стадії створення систем (ISO/IEC 15288)

Висновки

Завдання формування вимог до ІС є однієї з найбільш відповідальних, що важко формалізуються і найбільш дорогих і важких для виправлення у випадку помилки. Сучасні інструментальні засоби й програмні продукти дозволяють досить швидко створювати ІС по готових вимогах. Але найчастіше ці системи не задовольняють замовників, вимагають численних доробок, що приводить до різкого подорожчання фактичної вартості ІС. Основною причиною такого положення є неправильне, неточне або неповне визначення вимог до ІС на етапі аналізу.

Контрольні питання

1. Типові архітектури ІС

2. Навести основні етапи проектування.

3. Типи архітектур (сучасні та популярні).

4. Класифікація програмного забезпечення для автоматизації бізнес процесів.

5. Поняття систем управління, їх недоліки і переваги.

6. Класифікація систем автоматизації бізнес-процесів.

Література [2, 6, 7].

Лекція 4. Системи автоматичної ідентифікації: RFID або штрих-код.

Мета: викладення основних систем ідентифікації та використання на практиці.

План

4.1. Сфери використання автоматичних систем ідентифікації

4.2. Доцільність впровадження штрихкодів

4.3. Принципи кодування

4.3.1. Код EAN13

4.3.2. Код EAN128

4.4. Радіочастотна ідентифікація RFID

4.1. Сфери використання автоматичних систем ідентифікації

В даний час важко уявити собі ведення ефективного бізнесу без використання інформаційних технологій покликаних полегшити введення, зберігання та перетворення інформації, зменшити кількість ручних операцій і мінімізувати кількість помилок при введенні даних. Природно, що малий бізнес може обійтися і без засобів автоматизації, але як тільки ваш бізнес починає розростатися, відразу постає питання про автоматизацію процесу обліку. І тут вам на допомогу прийдуть системи автоматичної ідентифікації. Системи автоматичної ідентифікації дозволяють розрізняти різнорідні предмети за допомогою присвоєння кожному предмету унікального ідентифікатора (номера або коду). До предмету, що маркується, прикріплюється спеціалізована мітка, що містить ідентифікатор, який можна вважати спеціальним пристроєм - зчитувачем. Лічений ідентифікатор перетвориться в електронний вигляд. В якості ідентифікатора можна використовувати графічні, магнітні і радіочастотні мітки.

Засоби автоматичної ідентифікації найбільш затребувані:

• у торгівлі;

• в логістиці;

• в документообігу;

• в поштовій справі;

• в складальному виробництві;

• в системах контролю доступу;

• в системах управління бібліотеками та архівами;

• в системах управління складами і т.д.

В даний час «метрами» автоматичної ідентифікації товарів є технології штрих-кодування і радіочастотної ідентифікації (RFID). Обидві технології стали де-факто промисловими стандартами і зайняли свої ніші на ринку автоматичної ідентифікації.

Штриховий код - це послідовність чорних і білих смуг, що представляє деяку інформацію у вигляді, зручному для зчитування технічними засобами. Інформація, що міститься в коді, може бути надрукована в читається вигляді під кодом (розшифровка).

Штрихкоди були винайдені в США в кінці 1940х двома студентами Норманом Вудленд і Бернардом Сильвером як засіб автоматизованої обробки інформації про товари (патент # 2612994 від 1952 року). Існує відома легенда про те, що першим у світі товаром зі штрихкодом була жувальна гумка Wrigley. Насправді Wrigley була першим товаром з продовольчої візки, з якого був лічений штрихкод при проведенні демонстрації нової технології в магазині мережі Marsh в місті Трой, Огайо. Крім Wrigley в візку були й інші товари зі штрихкодом, але касир вибрав першими 10 пачок саме цієї знаменитої жувальної гумки.

Справжній прорив у поширенні штрихкодів трапився 1 вересня 1981 з рішенням міністерства оборони США використовувати код на основі кодування CODE39 для маркування всього товару, що закуповується міністерством на військові потреби. Точно так само зараз локомотивами впровадження штрихкодів на вторинній упаковці (тобто на коробках і ящиках) в Росії є такі компанії як Ашан і Мега, які «ввічливо натякають» на це виробникам.

4.2. Доцільність впровадження штрихкодів

Штрихкод - всього лише один із способів машинного зчитування інформації.

Як і все інше в цьому житті, технології окуповуються тільки там, де їх застосування доцільно. Всі технології в бізнесі можна умовно розділити на 2 групи: 1) інвестиційно-затратні, які зменшують собівартість одиниці продукції або послуги, і 2) збільшують собівартість, але приносять вигоду в чомусь іншому (наприклад, покупка комп'ютера прискорює набір і правку супутніх документів , а пастеризація молока зменшує загальні втрати).

Штрих-коди бувають лінійні (1D) і двомірні (2D). Лінійний код можна побачити на пачці соку або сигарет, а двовимірний - на алкогольній акцизної марки. Сам по собі будь лінійний штриховий код - це своєрідна азбука Морзе з точок і тире у вигляді смужок різної ширини з одним важливим доповненням: літери штрих-коду сильно відрізняються один від одного, а використовувані «правила письма» і «знаки» дозволяють незайвий раз перевірити правильність прочитаного. Відомо, що в штрих-коді не заховано нічого цікавого крім тих самих цифр, що вже написані під ним:

Рис 4.1. Приклад коду EAN13

Тобто «Закодовано» у даному випадку не означає «зашифровано і заховано». Виникає питання: чому так багато смужок і так мало інформації? У цифрах знизу це займає набагато менше місця! Ми звикли, що при комп'ютерному кодуванні цілі енциклопедії вміщаються на одній порошині, а тут такий витрату паперу. Цьому є одразу кілька причин. Причина № 1 - комп'ютери за $ 50 не вміють (або колись не вміли) читати занадто дрібний «текст». Причина № 2 - щоб дрібні пошкодження не змогли спотворити інформацію. Причина № 3 - щоб касирові було легше знайти штрих-код.

Питання: чи правда, що в штрих-коді «зашита» інформація про колір, розмір або ціною товару? Відповідь на нього потребує додаткових пояснень і дозволяє зрозуміти, що представляють із себе штрих-коди з точки зору бізнесу.

Принципи кодування

Існує велика кількість різних типів штрих-кодів, і це пояснюється різними вимогами різних бізнесів, тобто областю застосування. Т.к. штрих-код - це особлива мова, у будь-якого типу штрих-кодів є свій алфавіт і свій словник. Під алфавітом розуміється правила кодування за допомогою «штрихів» окремих цифр, букв та інших знаків, дозволених в даній системі кодування. А під словником - що означають ці цифри і букви всередині коду, де вони повинні стояти і т.д. Іноді, як у випадку з EAN13, алфавіт і словник називаються однаково, хоча це абсолютно різні речі. Відмінності між цими поняттями можна зрозуміти в наступному порівнянні:

Розглянемо це докладніше на прикладі коду EAN13:

Код EAN13

Код EAN13, ймовірно, найпоширеніший код на планеті, тому він присутній на всіх продовольчих товарах. Абревіатура EAN означає Європейський Номер Артикулу (European Article Number). EAN13 унікальний тим, що він має, крім власного формату (словника), ще й власний алфавіт. Крім EAN13 схожим алфавітом користується тільки EAN8. Тобто, якщо хтось говорить «EAN13», він відразу як би говорить і про систему кодування, і про формат, і про те, як це виглядає:

Рис 4.2. Розбір коду EAN13

На малюнку видно, що код складається з двох груп штрихів, обмежених роздільниками «| |». EAN13 дозволяє закодувати 12 значущих цифр. Остання цифра коду - чексумма, завжди обчислюється за певною формулою з важливих 12-ти і використовується таким чином: сканер відновлює зі штрихів всі 13 цифр, а з перших 12ти вважає чексумму. Якщо чексумма і тринадцятий цифра збіглися - «піііп», код лічений вірно. Більш конкретно:

якщо сканер невірно прочитає якісь цифри всередині коду, але вірно прочитає чексумму (наприклад, йому «здасться», що замість «2457852111114» на коробці написано «2417852111114»), то можна буде обчислити чексумму для перших 12-ти прочитаних цифр і побачити , що вона не збігається з 13-ю прочитане цифрою, а повинна (в даному випадку чексуммой коду «241 785 211 111» є не «4», а «8», тобто сканер тоді вже мав би прочитати «2417852111118», а не «2417852111114»), що і дозволяє зловити помилку.

якщо ж сканер вірно прочитав перші 12 цифр, але невірно прочитав чексумму, то вона знову не співпаде з обчисленою, і вірити такому кодом (або сканера) теж не можна.

Крім блоків номерів, будь коди EAN13, які починаються з префіксів 20-29, можуть бути використані підприємством для целейвнутреннего обліку (тобто такі штрихкоди будуть унікальні тільки всередині організації, ЮНІСКАН за ними не стежить і нікому такі номери не видає).

У загальному випадку в коді EAN13 не зберігається інформації про колір, розмір чи інших характеристиках конкретної одиниці товару.

Отже, в коді присутні 13 цифр, з яких використовувати для зовнішньої торгівлі організація може тільки 3, 4 або 5 цифр (по домовленості з ЮНІСКАН). Замало. Де ж зберігати колір і розмір? В електронному каталозі виробника!

Для внутрішніх кодів, що починаються на 20-29, в організацій вже більше місця для творчості. У них можна помістити і вага, і колір, і розмір. Наприклад, електронні ваги для овочів і фруктів друкують такі коди - на касі з нього буде правильно вичленований і внутрішній артикул, і вага. В іншому магазині такої штрихкод швидше за все не зрозуміють.

Отже, відповідь для коду EAN13 знайдений: в загальному випадку в коді EAN13 не зберігається інформації про колір, розмір чи інших характеристиках конкретної одиниці товару. У ньому зберігаються країна, фірма та номер товару. При цьому для оригінальних штрих-кодів на упаковці виробника каса не сприймає EAN13 як щось, що можна розібрати по частинах. У переважній більшості випадків всі 13 цифр EAN13, разом з чек-сумою, використовуються як унікальний цифровий код номенклатури, на зразок артикула.

Код EAN128

EAN128 призначений для передачі даних про вантаж між компаніями.

EAN128 є, мабуть, другим по поширеності кодом на планеті, і ось чому: це код для обміну інформацією про товари та вантажі між виробничими, транспортними і торговельними компаніями:

Рис 4.3. Розбір коду EAN128

4.4. Радіочастотна ідентифікація RFID

RFID (англ. Radio Frequency IDentification, радіочастотна ідентифікація) - метод автоматичної ідентифікації об'єктів, в якому за допомогою радіосигналів зчитуються і / або записуються дані, що зберігаються в так званих RFID-мітках.

Історично першим з'явилася технологія штрих-кодування і у відсутність яких-небудь реальних конкурентів стрімко зайняла ринок ідентифікації. У наш час важко знайти товар не маркований штрих-кодом. Подальшим розвитком засобів автоматичної ідентифікації стала технологія RFID. Обидві технології мають свої недоліки і переваги.

Розглянемо обидві технології автоматичної ідентифікації на основі розгляду їх функціональних можливостей.

Можливість перезапису. Більшість RFID-міток можуть перезаписуватися і доповнюватися багато разів, тоді як дані на штрих-коді не можуть бути змінені - вони записуються тільки один раз при виготовленні мітки.

Простота зчитування. Для технології RFID не потрібна пряма видимість між міткою і зчитувачем. Просторова орієнтація мітки і зчитувача практично не має значення. RFID-мітки чудово читаються через упаковку, що робить можливим їх приховане розміщення та облік товарів без їх розпакування. Для читання даних RFID-мітки досить ненадовго потрапити в зону реєстрації. Навпаки, пристрою зчитування штрих-коду завжди необхідна пряма видимість штрих-коду для його читання, плюс дуже важливо щоб штрих-код не був забруднений або деформований. Практично кожному знайома ситуація, коли касир у супермаркеті не може вважати штрих-код ні за допомогою зчитувача, ні навіть візуально.

Відстань зчитування. Для штрих-коду відстань зчитування обмежується 2-3 метрами. RFID-мітка може зчитуватися на відстанях від декількох сантиметрів до декількох десятків метрів. В залежності від моделі RFID-мітки і зчитувача, відстань зчитування може становити до декількох сотень метрів. Хоча такі відстані не завжди потрібні.

Обсяг збережених даних. RFID-мітка може зберігати до декількох кілобайт інформації. У той час як штрих-код може вмістити до 100 байт (знаків) інформації при розмірі мітки з аркуш формату А4.

Можливість читання декількох міток. RFID-зчитувачі можуть одночасно зчитувати до декількох сотень RFID-міток в секунду, використовуючи механізм антіколлізіі. Пристрій зчитування штрих-коду може одночасно зчитувати тільки один штрих-код.

Ідентифікація рухомих об'єктів. Зчитування штрих-коду з рухомого об'єкту скрутно і в більшості випадків практично неможливо. Зчитування ж RFID-мітки при русі не представляє труднощів, головне щоб мітка потрапила в зону дії зчитувача.

Наявність перешкод в роботі. Для зчитувачів штрих-коду практично не існує ні промислових, ні природних перешкод. RFID-зчитувачі схильні заважає впливу електромагнітних полів, також робота RFID-міток погіршується (зменшується відстань зчитування) при використанні їх на металевій поверхні.

Стійкість до впливу навколишнього середовища. Як правило, RFID-мітки виконані в герметичному корпусі, що володіє досить високою міцністю і стійкістю до агресивних умов навколишнього середовища. Штрих-код же легко пошкоджується вологою або забрудненням. Якщо один і той же об'єкт використовується багаторазово, наприклад, при ідентифікації контейнерів або зворотної тари, RFID-мітка не має альтернативи.

Захист від підробки. При виготовленні RFID-мітки їй присвоюється унікальний незмінний ідентифікатор, який, гарантує досить високий ступінь захисту міток від підробки. Більшість RFID-міток використовує зашифровану передачу та зберігання даних. В одній RFID-мітки можна одночасно зберігати відкриті і закриті дані. Штрих-код легко підробити використовуючи звичайну офісну техніку, для цього його досить його відсканувати і роздрукувати.

Доступність стандартів для розробників систем. Стандарти, що описують штрих-кодування є більш відкритими і доступними ніж стандарти технології RFID. Останні ж розробки в області RFID часто залишаються надбанням виробника не охочим розкривати ноу-хау.

Термін життя мітки. Термін життя RFID-мітки може становити до 10 років, і залежить від конкретних умов експлуатації. Термін життя штрих-коду значно менше і дуже залежить від матеріалу мітки і поверхні, на яку вона наноситься.

Вартість. Вартість системи обліку на базі RFID значно вище вартості системи на базі штрих-коду за рахунок більш високої вартості міток.

На даний момент технологія штрих-кодування лідирує за масовістю застосувань, хоча технологія RFID надає більше переваг і є більш перспективною. Ситуація ускладнюється тим, що користувачі системи штрих-кодування вкладені колосальні кошти в купівлю обладнання використовує саме цю технологію. Суттєвими перевагами штрих-кодування є низька ціна міток і простота їх виготовлення.

Забігаючи наперед можна прогнозувати, що за рахунок інерційності ринку ідентифікації технологія штрих-кодування якийсь час ще буде лідирувати на ринку ідентифікації, але незабаром поступиться своє місце RFID. У будь-якому випадку доцільність застосування тієї чи іншої технології залежить від конкретних умов і цілей її застосування.

Контрольні питання

1. Технології електронного обміну даними.

2. Технології штрих-кодування.

3. Технології радіочастотної ідентифікації.

4. Відстежування матеріальних потоків в реальному режимі часу.

Література [2, 6, 7].

1. Змістовий модуль 2

ІНФОРМАЦІЙНІ СИСТЕМИ В ЛОГІСТИЦІ.

Лекція 5. Загальний аналіз сучасних систем управління.

Мета: Викладання основних ідей щодо вибору систем, аналіз додаткових можливостей.

План

5.1. Чотири стадії розвитку ПЗ керування компанією

5.2. Використання новітніх систем на теренах СНД

5.3. Три складові частини BPM

5.4. Агресивний маркетинг

5.4.1. BPM-система - це просто Сховище даннях

5.4.2. Рішення, побудоване на основі Сховища даних, - це BPM-система

5.4.3. Система бюджетування - це BPM-рішення

Все більше компаній, які пропонують вітчизняним замовникам ПО класу Business Performance Management (BPM, управління ефективністю бізнесу). Чи всі системи насправді забезпечують комплексну автоматизацію технологій управління компанією? Розглянемо системи автоматизації управління корпоративного масштабу - системи BPM.

Історія пізнавальної діяльності людства показує, що становлення нового неминуче супроводжується помилками, неправильними логічними побудовами і помилковими теоріями. У минулому можна назвати навіть цілі наукові сторіччя, коли невірні положення приймалися за істину. В області сучасних інформаційних технологій омани і крайнощі часто стають перешкодою на шляху до адекватного сприйняття передових програмних розробок.

Немає нічого дивного в тому, що думки та оцінки відносно молодий і "модною" сьогодні теми автоматизації технологій корпоративного управління часто грішать проти істини. Омани обумовлені складністю обраної області автоматизації, відносної обмеженістю інформації та плутаниною, яку вносять самі розробники, які прагнуть зайняти своє місце на тільки ринку, що формується управлінського програмного забезпечення. Невинна, на перший погляд, підміна в термінології, позначення цілей і розв'язуваних завдань і ін, в результаті може обернутися невірним вибором засобів автоматизації однієї з найважливіших областей бізнесу.

5.1. Чотири стадії розвитку ПЗ керування компанією

Отже, які завдання вирішують системи BPM, і як е місце вони займають серед іншого ПО автоматизації бізнес-процесів?

Для відповіді на це питання скористаємося матеріалами звіту Best Practices in Business Performance Management: Business and Technical Strategies (Успішний досвід управління ефективністю бізнесу: бізнес та технічні стратегії) Міжнародного Інституту дослідження Сховищ даних (The Data Warehousing Institute, TDWI). Автори звіту, підготовленого влітку 2004 року, позиціонують BPM-системи, аналізуючи загальну схему розвитку ПЗ для автоматизації бізнес-процесів за останні двадцять років (див. приклад схеми на рис.5.1).

Рис. 5.1. Схема розвитку ПЗ для автоматизації бізнес-процесів

Простежимо за представленою на схемі TDWI логікою розвитку автоматизованих систем підтримки бізнесу. Спочатку з'явилися системи автоматизації бек-офісних процесів, перш за все, виробництва та бухгалтерського обліку. Потім прийшла черга фронт-офісу: продажів, послуг, маркетингу. В кінці двадцятого століття організації перейшли до автоматизації перехресних процесів, які зачіпають роботу декілька підрозділів, впроваджуючи технології управління взаєминами з клієнтами - CRM, і технології управління ланцюгами поставок - SCM. І, нарешті, вершина піраміди, яку стали автоматизувати зовсім недавно - це корпоративне управління. Для вирішення цього завдання в світі виділяють спеціальний клас програмного забезпечення - BPM-системи.

Рух вгору по рівнях піраміди відбиває поступовий перехід від автоматизації оперативних бізнес-процесів до автоматизації стратегії управління бізнесом. Процеси на більш високих рівнях піраміди контролюють процеси на більш низьких рівнях. Таким чином, BPM-системи призначені для автоматизації стратегічного планування розвитку бізнесу і, одночасно, для підтримки тактичного (або оперативного) управління бізнес-процесами на різних рівнях. Завдання BPM-систем - допомогти в реалізації стратегічних цілей бізнесу в реальних умовах. Для цього вони повинні забезпечувати користувача потрібною інформацією в потрібний час, щоб підвищити ефективність управління оперативною діяльністю.

5.2. Використання новітніх систем на теренах СНД

Періоди появи і формування різних класів ПО, вказані на схемі TDWI, відображають світовий досвід і не збігаються з часом, появи тих чи інших технологій і інструментів у вітчизняних компаніях. В області автоматизації бізнесу Росія, Україна традиційно відставали від своїх західних колег, хоча в останні роки ми поступово надолужувати згаяне. Якщо різниця для нижніх рівнів піраміди відчутна (скажімо, пік автоматизації бек-офісних, облікових завдань прийшовся в Росії на 1992-1993 рік, а в світі це сталося на 5-7 років раніше), то для систем керування масштабу корпорації відставання складає вже не більше 2 років.

В якості часу появи у світі самостійного класу програмного забезпечення для комплексної підтримки управлінських технологій TDWI позначає початок XXI століття. Проте в Росії і країнах СНД в 2000-2001 роках впроваджень BPM-систем майже не було, вони стали активно з'являтися в 2002 році. А сам термін "BPM" прийшов на вітчизняний ринок ще пізніше, на рубежі 2003-2004 років.

В даний час в Росії, Україні та Казахстані налічується близько 200 завершених проектів по впровадженню систем управління рівня корпорації, з них приблизно третина - більше 60 - виконано для кредитних організацій. При цьому темпи зростання російського ринку BPM-систем випереджають світові.

Дослідницька компанія Gartner за підсумками 2004 року оцінює зростання обсягів продажів BPM-систем у світі на рівні 11%. У Росії міжнародні аналітичні компанії поки не проводили аналогічні дослідження, проте за даними Intersoft Lab, провідного постачальника в цьому сегменті ринку, в 2004 році зростання обсягів продажів BPM-систем "Контур" по Росії, Казахстану і Україні склав 28% в цілому, а конкретно з банківського сегменту - 34%. Кількість контрактів на впровадження BPM-рішень на платформі "Контур", укладених в перші три місяці поточного року, в два рази перевищило показники за аналогічний період минулого року. Таким чином, факти свідчать про стабільну динаміку зростання попиту на BPM-рішення в Росії і країнах СНД.

5.3. Три складові частини BPM

Функціональна архітектура класичної BPM-системи банку складається з трьох складових частин. Перша частина - Сховище даних. Це базис BPM-системи. У ньому консолідується оперативна фінансова інформація з різних автоматизованих модулів Головного офісу та філій організації, з дочірніх компаній. Друга складова рішення - набір інструментів для підтримки технологій управління підприємством: фінансового планування, управлінського обліку, прогнозування і т.д. Третя компонента BPM - засоби OLAP для оперативної роботи з діловими даними, які накопичуються в Сховище.

Таким чином, BPM-системи не можна назвати чимось принципово новим. Вони об'єднують відомі управлінські технології і програмні рішення, які перш застосовувалися локально і вирішували завдання окремих підрозділів і користувачів.

Рис. 2. Етапи та інструменти циклу корпоративного управління

У чому ж переваги і новизна BPM-підходу? Справа в тому, що BPM-система призначена для підтримки ПОВНОГО ЦИКЛУ управління компанією. Це означає, що інструменти BPM взаємопов'язані і забезпечують виконання чотирьох основних етапів управління ефективністю бізнесу (див. рис.2):

1 етап. Розробка стратегії. Мета першого етапу - виділення цільових показників бізнесу і планування кількісних значень їх метрик - KPI (Key Performance Indicators, ключових показників ефективності). Стратегічне планування спирається на одну з методологій BPM, відому як BSC (BalancedScorecard, система збалансованих показників).

2 етап. Планування. На другому етапі розробляються тактичні плани для досягнення поставлених стратегічних цілей. Орієнтирами для розробки тактичних (оперативних) планів стають KPI. Основним інструментом оперативного планування є бюджет.

3 етап. Моніторинг і контроль виконання. Третій етап у циклі корпоративного управління - моніторинг та контроль виконання бюджетних планів. Фактичні значення за статтями управлінського обліку обчислюються на основі зібраних у Сховище первинних даних. Для порівняння намічених і досягнутих показників бюджетів та KPI використовуються інструменти "план-фактного" ​​аналізу на основі технології OLAP.

4 етап. Аналіз і регулювання. На заключному етапі стратегічні плани коригуються у відповідності з реальними умовами роботи банку. Для планування змін використовуються інструменти прогнозування та моделювання різних сценаріїв розвитку ситуації. У підсумку цикл корпоративного управління - між вибраною банком стратегією і її практичною реалізацією - замикається.

Таким чином, за допомогою BPM-системи створюється цілісна інфраструктура для підтримки узгодженого стратегічного і тактичного управління банком на основі єдиної моделі даних. У цьому принципова відмінність комплексного підходу систем автоматизації управління масштабу корпорації від ізольованого вирішення окремих управлінських задач.

Однак, комплексний підхід не виключає етапність при виконанні BPM-проектів в банках. Використання покрокової технології впровадження BPM-систем прийнято у всьому світі, і Росія не є винятком. Замовники починають «з малого» - спочатку використовують BPM-платформу для підтримки якоїсь однієї управлінської технології (у вітчизняних банках це, найчастіше, управлінський облік і підготовка управлінської звітності), а потім поступово нарощують функціональність, впроваджуючи повний цикл управління реалізацією корпоративної стратегії . Прагматизм в даному випадку цілком зрозумілий - поетапний підхід дозволяє в короткі терміни отримати перші результати від впровадження нових управлінських технологій та оцінити їх практичну користь. Крім того, менеджмент банку може контролювати і своєчасно коригувати розвиток проекту.

До питання про термінологію: BPM, CPM, EPM ...

Поняття BPM вперше було запропоновано аналітичною компанією IDC. Такий же термінології сьогодні дотримується інша авторитетна дослідницька організація - META Group. Серед рішень, представлених на російському ринку, концепції BPM повністю відповідає ПЗ компаній Hyperion, SAS, Intersoft Lab і деяких інших.

Однак, на сторінках спеціалізованих ЗМІ можна зустріти різноманітні абревіатури, якими аналітики і розробники позначають системи автоматизації управління масштабу корпорації. Термінологічний коктейль неначе спеціально створюється, щоб заплутати читача. Крім BPM, найбільш поширені скорочення CPM (Corporate Performance Management, управління ефективністю корпорації) і EPM (Enterprise Performance Management, управління ефективність підприємства). Що ховається за цими абревіатурами, і в чому їх відмінність від BPM?

За визначенням Gartner, управління ефективністю корпорації (СРМ) - це комбінація методик (на приклад, Balanced Scorecard), показників (фінансових і нефінансових, довгострокових і короткострокових та ін), процесів (на приклад, розробка стратегії, бюджетування, прогнозування) та систем , використовуваних для контролю і управління продуктивністю ділової діяльності організації. З позиції реалізації, СРМ-система об'єднує ті ж функціональні блоки, що і bрм-рішення: Сховище даних, інструменти автоматизації методик управління ефективністю і OLAP. Це означає, що терміни СРМ та bрм не мають суттєвої різниці за змістом. Хоча ряд авторитетних зарубіжних експертів, розглядаючи концепцію корпоративного управління стосовно до банківського сектору, використовують саме це скорочення. Серед західних постачальників ПО цьому у термінові в позначенні власних програмних розробок віддають перевагу Cognos і Oracle.

Абревіатуру EPM в переважній більшості випадків використовують як прямий синонім BPM і СРМ. Однак, деякі автори вкладають в неї більш широкий зміст, і крім традиційних компонентів відносять до ключових складових EPM-системи довідкові дані, вихідні системи і додатки, пов'язані на основі Сховища даних. Тим самим, на відміну від BPM, в складі EPM-рішення виділяється самостійний шар джерел даних. Виправдовуючи свою назву, EPM частіше застосовують для позначення управлінських рішень, що вибудовуються для підприємств.

Значно рідше вживають поняття ECM (Enterprise Commerce Management, управління комерційною діяльністю підприємства). Його, як альтернатива BPM, запропонувала незалежна аналітична фірма AMR Research.

Ще одна абревіатура, яка час від часу заміщає BPM на сторінках електронних видань, - це BAM (Business Activity Management, управління діловою активністю). До завдань систем цього класу відносять, перш за все, контроль бізнес-процесів на основі вимірювання KPI в інтегрованій бізнес-середовищі. Ця концепція більше орієнтована на рішення частини завдань BPM, пов'язаної з обліком та аналізом фактичного стану бізнесу, і не зачіпає ділове планування.

Після всього сказаного стає очевидним, що нагромадження термінів і скорочень не міняє суті розглянутих рішень. Майже всі перераховані BPM / CPM / EPM-платформи призначені для управління реалізацією корпоративної стратегії на основі єдиної інформаційної моделі організації.

Агресивний маркетинг

У Росії стає все більше компаній, які пропонують вітчизняним замовникам ПО класу BPM. Але чи всі системи насправді забезпечують комплексну автоматизацію управління компанією? Як відрізнити справжні можливості програмного продукту від нав'язуваного агресивним маркетингом помилкового уявлення, як з'ясувати, де в словах постачальника правда, а де просто реклама, яка експлуатує "модне" поняття? Спробуємо розкрити найпоширеніші помилки щодо BPM.