Розробка ІС підприємства оптової торгівлі лікарськими препаратами
ВСТУП
Статичні і динамічні моделі будуються тільки для основних видів діяльності організації і лише в тому об'ємі і з той ступенем подробиці, яка забезпечує формування вимог до ІС. При визначенні вимог до інформаційних систем це дозволяє обмежитися уявленням тільки інформаційних процесів, пов'язаних з наданням послуг клієнтам.
Інформаційні системи розбиваються на сукупність архітектури, кожна з яких описує різні аспекти ІС з різних точок зору. Це дозволяє розділити формування вимог ІС на ряд ітераційно виконуваних кроків, на кожному з яких вирішувані завдання побудови моделей і дослідження варіантів архітектури мають меншу розмірність і простіші, ніж все завдання визначення вимог до ІС в цілому.
При побудові моделей використовується принцип проектування по методу зверху "вниз" і ось загального до приватного", що дозволяє спростити вирішення завдань без втрати якості і обмежитися уявленням в моделях тільки головних деталей і в тому об'ємі, який необхідний для визначення набору вимог до конкретної архітектури інформаційної системи на черговому рівні її деталізації.
При побудові статичних і динамічних моделей доцільно використовувати об'єктно-орієнтований підхід, який дозволяє понизити розмірність і трудомісткість проектування моделей за рахунок їх розумної декомпозиції і виділення повторно використовуваних типових фрагментів, які використовуються як базові конструктивні елементи моделей.
Використання цих угод дає реальну основу для подолання труднощів, пов'язаних з розмірністю моделювання великомасштабних організацій при визначенні вимог до їх інформаційних систем.
Підхід заснований на використанні могутніх засобів для побудови моделей: CASE-средств для побудови статичних моделей і автоматизації моделювання функцій, даних і структури організації і інформаційної системи, і інтелектуальних засобів для побудови динамічних моделей організації і інформаційної системи і проведення динамічного моделювання процесів.
Методична схема ітераційного проектування інформаційних систем і уточнення вимог до них, а також реинжиниринга бизнес-процессов за допомогою сучасних засобів інтелектуального динамічного моделювання полягає в наступному.
Вимоги і специфікації проекту великої системи на будь-якому рівні деталізації виражаються через сукупність архітектури ІС, що описують з різних точок зору її майбутню зовнішність. Основними з цієї архітектури є архітектура системотехнической платформи, архітектура телекомунікаційної системи і архітектура прикладного програмно-інформаційного забезпечення.
Відправною точкою процесу проектування ІС може служити побудова початкової моделі даної організації і використовуваних в ній в даний час інформаційних систем. Ці моделі служать джерелом витягання метричних характеристик початкових вимог і обмежень, що виставляються до перших архітектурних образів майбутньої ІС. Далі будується динамічна моделі цієї архітектури, на якій оцінюються їх основні метрики і на цій основі контролюється рівень задовільності і якість пропонованих рішень.
Попередня інформація
Вважається, що на початку обслідування проведено попередній збір інформації про компанію, за результатами якого отримані наступні дані:
Коротка інформація про компанію (профіль клієнта).
Цілі проекту.
Підрозділи і користувачі системи.
На підставі попередньої інформації сформовано і узгоджено с замовником загальне уявлення про проект:
Бачення виконання проекту і границі проекту - документ, який коротко описує, у яких підрозділах і у який функціональності буде впроваджуватись ІС. Після чого буде виконуватись детальне дослідження підприємства, результати якого оформлюються у вигляді окремого документа - звіту про обслідування.
Звіт про обслідування містить наступні розділи:
Аналіз існуючого рівня автоматизації.
Складається список програмного забезпечення, яке використовується у компанії, і приводяться дані про використання цих пакетів у кожному з підрозділів організації.
Загальні вимоги до ІС.
Формулюються Загальні вимоги до функціональності системи, що розроблюється.
Форми документів.
Визначається перелік і структура документів, які повинні формуватись системою.
Опис системи обліку.
Опис системи обліку включає в себе наступні документи:
Облікова політика компанії.
План рахунків і використаних аналітик.
Список типових господарських операцій і їх відображення у проводках.
Опис довідників
По кожному довіднику, проектованому у системі, дається опис необхідної ієрархічної структури.
Організаційна діаграма.
Організаційна діаграма використовується для відображення організаційної структури підрозділів підприємства і їх зон відповідальності.
Опис складу бізнес-процесів, що автоматизуються.
Всі бізнес-процеси компанії повинні бути перераховані у загальному списку і кожен повинен мати свій унікальний номер.
Діаграми прецедентів.
Для виділення бізнес-процесів, що автоматизуються і їх основних виконавців використовуються діаграми прецедентів.
Фізична діаграма.
Фізична діаграма служить для того, щоб описати взаємодію організації на верхньому рівні з зовнішніми контрагентами.
Описи бізнес-процесів (книга бізнес-процесів).
У подальшому у звіт про дослідження включається книга бізнес-процесів, яка містить детальний опис автоматизованих бізнес-процесів. Моделі бізнес-процесів дозволяють виділити окремі операції, виконання яких повинно підтримуватись ІС, що розробляється.
На останньому етапі здійснюється відображення моделі предметної області на функціональність типової системи - обираються модулі системи для підтримки виділених операцій, визначаються особливості їх настройки, виявляється необхідність розробки додаткових програмних елементів.
Коротка інформація про компанію "МЕД"
Компанія - дистриб’ютор "МЕД" закупає медичні препарати вітчизняного і закордонного виробників і реалізує їх через власну дистриб’юторську мережу і мережу аптек. Компанія здійснює доставку товарів як власним транспортом, так і за допомогою послуг сторонніх організацій.
Основні бізнес-процеси компанії - закупки, складування запасів, продаж, взаєморозрахунки з поставщиками і клієнтами.
Рівень конкуренції для компанії в останній час виріс, тому що на ринок вийшли два нових конкурента, до яких перейшла частина клієнтів і ряд найбільш кваліфікованих співробітників ЗАО "МЕД". ЗАО "МЕД" має два філіали - у Лубнах і Нових Санжарах. Кожний філіал функціонує як самостійна юридична особа, являючись повністю приналежними ЗАО "МЕД" дочірньою компанією.
За попередніми планами, Компанія має намір відкрити також дочірнє підприємство для організації виробництва у безпосередній близькості до своїх замовників.
Адреса и телефони
Полтава, Центральна вулиця, д. 20, офіс 709
Телефон: (053) 45-67-89, факс: (053) 45-98-76
Контактні особи
Борис Петренко - Генеральний директор
Дмитро Кононов - Виконавчий директор
Артур Іванченко - Директор по маркетингу
Співробітники
На момент проведення Діагностики штат компанії складав 110 співробітників.
Основними цілями проекту автоматизації компанії "МЕД" є:
Розробка і впровадження комплексної автоматизованої системи підтримки логістичних процесів компанії.
Підвищення ефективності роботи всіх підрозділів компанії і забезпечення ведення обліку у єдиній інформаційній системі.
Бачення виконання проекту і границі проекту
У рамках проекту розгортання нової системи передбачається здійснити тільки в наступних підрозділах ЗАО "МЕД":
Відділ закупок;
Відділ прийомки;
Відділ продаж;
Відділ маркетингу;
Група планування і маркетингу;
Група логістики;
Обліково-операційний відділ;
Обліковий відділ;
Відділ сертифікації (у частині обліку сертифікатів на медикаменти);
Бухгалтерія (тільки у частині обліку закупок, продаж, постачання і платежів).
Не розглядаються у границях проекту автоматизація обліку основних засобів, розрахунків і начислення заробітної плати, управління кадрами. Виходить за рамки проекту автоматизація процесів взаємовідношень з клієнтами.
Кількість робочих місць користувачів - 50.
Звіт про обслідування
Список програмного забезпечення, що використовується компанією на момент обслідування
"1С: Предприятие 7.7" ("Бухгалтерия", "Торговля", "Зарплата", "Кадры", "Касса", "Банк") для роботи бухгалтерії.
Дві власні розробки на базі конфігуратора "1С" - "Закупки" і "Продажи".
Власна розробка на базі FOXPRO для фінансового відділу.
Excel для планування продаж.
Завдання 1. Побудова діаграми дій на підставі бізнес-процесу "Планування закупок і розміщення замовлень поставщикам"
На підставі загального опису бізнес-процесу "Планування закупок і розміщення замовлень поставщикам" скласти діаграму дій, яка показує учасників процесу, виконані кожним учасником операції і взаємозв’язок між ними. Операції на діаграмі повинні слідувати у хронологічному порядку, який визначено у наведеному опису бізнес-процесу.
1. У пунктах №1, 2 приведені описи учасник процесу - "Менеджер групи планування і маркетингу"
2. В пунктах № 3, 4 - "Менеджер відділу закупівель"
3. Введення в систему прайс-листів постачальників (операція № 3)
4. Аналіз речень постачальників (операція № 4)
5. Вибір постачальників (операція № 5)
6. Формування графіка постачань без вказівки кількості (операція № 6)
7. Розрахунок необхідної кількості закупівель (операція № 7);
8. Формування замовлень постачальникам (операція № 8);
9. Розрахунок витрат на сертифікацію імпортних товарів, якщо медикаменти імпортні.*) (операція № 9); Перевірка суми витрат на сертифікацію на неперевищення внутрішньофірмової норми*);
10. Формування замовлень постачальникам при перевищенні витрат на сертифікацію (операція № 10);
11. Підпис замовлення (операція № 11);
Завдання 2. Формування таблиці опису документів.
Всі документи, які приймають участь у бізнес-процесі, відобразіть у Таблиці опису документів, яка має наступний формат:
|
Діаграма і номер на діаграмі |
Складений документ (вихідний документ) |
Операція |
Хто складає (виконавець) |
Як часто |
Документи - основи (вхідні документи) |
Реєстр, у якому реєструється документ |
Коментар |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Діаграма і номер на діаграмі |
Складений документ (вихідний документ) |
Операція |
Хто складає (виконавець) |
Як часто |
Документи - основи (вхідні документи) |
Реєстр, у якому реєструється документ |
Коментар |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
1Пл_Зак 2 |
1. Таблиця потреб в товарі |
Розрахунок потреб в товарі |
Менеджер гр. планування і маркетингу |
Щотижня |
Звіт-таблиця власних продажів |
Реєстр статистичних звітів |
|
|
1Пл_Зак 3 |
2. Список постачальників |
Аналіз пропозицій постачальників і контрактів, що діють |
Менеджер відділу закупівель |
Щомісячно і в міру необхідності |
Прайс-листи постачальників Діючі контракти |
Реєстр прайс-листів |
|
|
1Пл_Зак 4 |
3. Список постачальників з розстановкою пріоритетів |
Вибір постачальників |
Менеджер відділу закупівель |
Щомісячно і в міру необхідності |
Список постачальників |
Ні |
|
|
1Пл_Зак 5 |
4. Графік постачань |
Формування графіка постачань без вказівки кількості |
Менеджер відділу закупівель |
Щомісячно і в міру необхідності |
Список постачальників з розстановкою пріоритетів |
Ні |
|
|
1Пл_Зак 6 |
5. План заявок на місяць |
Розрахунок необхідної кількості закупівель з урахуванням залишку на складі і страхового запасу |
Менеджер групи логістики |
Щомісячно і в міру необхідності |
Таблиця потреб в товарі, прайс-листи постачальників, графік постачань |
Ні |
|
|
1Пл_Зак 7 |
6. Замовлення постачальников |
Формування замовлень постачальникам з урахуванням складських залишків, товару в дорозі і резервного запасу |
Менеджер групи логістики |
Щодня за планом заявок |
План заявок на місяць, графік постачань, прайс-листи постачальників |
Реєстр замовлень |
|
|
1Пл_Зак 9, 10 |
7. Звіт про витрати на сертифікацію |
Розрахунок затратов на сертифікацію Перевірка витрат на неперевищення норми |
Менеджер групи логістики |
По мірі необхідності |
Замовлення постачальникові |
Ні |
|
|
1Пл_Зак 11, 12, 13 |
8. Замовлення постачальникові що акцептуються |
Підпис замовлення менеджером по логістиці Напрям замовлення у відділ закупівель Напрям замовлення постачальникові |
Менеджер групи логістики |
Щоденно |
Замовлення постачальникові що акцептуються |
Реєстр замовлень |
Таблиця опису документів виходить шляхом переформовування (перестановки стовпців і об'єднанні рядків) таблиці опису операцій. Особливості таблиці опису документів полягають в наступному. У Графі 2 не повинно бути найменувань документів, що повторюються. Якщо один і той же документ є витікаючим на різних операціях, то він один раз указується в графі 2 документ", що "Складається, а в графі 3 йому у відповідність ставляться декілька операцій. Також по найменуванню документа слід об'єднати записи і в інших графах.
У графі 7 указується найменування реєстру, в якому реєструється створюваний документ. Найменування реєстру привласнюється, як правило, по найменуванню документа. Наприклад, якщо документ "Замовлення", то "Реєстр замовлень"; документ "прайс-лист", тоді "реєстр прайс-листів" і т.д.
Завдання 3. Побудова діаграми дій на підставі бізнес-процесу "Продаж"
На підставі загального опису бізнес-процесу "Продаж" складіть діаграму дій, яка показує учасників процесу, виконані кожним учасником операції і взаємозв’язок між ними. Операції на діаграмі повинні слідувати у хронологічному порядку, який визначений у наведеному описі бізнес-процесу.
Дії (операції), що виконуються менеджером відділу продажу:
1. Операція № 1 "Отримання ось клієнта замовлення з вказівкою номенклатурних одиниць товару по кількості, серійній відповідності, терміну придатності"
2. Операція №2 "Перевірка наявності в клієнта ліцензії на замовлені медикаменти";
3. Операція № 3 "Перевірка наявності товарних запасів на складе"
4. Операція № 4 "Розміщення замовлення в реєстрі незадоволений попит";
5. Операція № 5 "Процес формування заявки на підставі замовлення і договору";
6. Операція № 6 "Резервування товару";
7. Операція № 7 "Контроль кредитного ліміту і дебіторської заборгованості";
8. Операція № 8 "Відхилення заявки".
Завдання 4. Формування таблиці операцій на основі процесу "Взаєморозрахунків з клієнтами"
Всі операції, які приймають участь у процесі "Взаєморозрахунки з клієнтами" відобразіть у Таблиці опису операцій, яка має наступний формат:
|
Діаграма і номер на діаграмі |
Складений документ (вихідний документ) |
Операція |
Хто складає (виконавець) |
Як часто |
Документи-основи (вхідні документи) |
Реєстр, у якому реєструється документ |
Коментар |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Діаграма і номер на діаграмі |
Складений документ (вихідний документ) |
Операція |
Хто складає (виконавець) |
Як часто |
Документи-основи (вхідні документи) |
Реєстр, у якому реєструється документ |
Коментар |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Склад |
Рахунок постачальника |
Отримання від постачальника |
Менеджер відділу закупок |
Щоденно |
Реєстр рахунків постачальників |
Реєстр рахунків постачальників |
|
|
Склад |
Платіжне доручення |
Формування платіжного доручення |
Бухгалтер |
Щоденно |
Платіжне доручення |
Платіжне доручення |
|
|
Склад |
Реєстр рахунків постачальників |
Створення відмітки |
Бухгалтер |
По мірі необхідності |
Виписка з розрахункового рахунку банка |
Виписка з розрахункового рахунку банка |
|
|
Склад |
Журнал надходжень і оплат |
Створення запису |
Менеджер відділу закупок |
По мірі необхідності |
|||
|
Склад |
Вивід сальдо |
Бухгалтер |
В кінці кожного місяця |
Бізнес-процес виглядає наступним чином:
Менеджер відділу закупок щоденно отримує від постачальника медикаментів рахунок на оплату, реєструє його у реєстрі рахунків постачальників і передає рахунок постачальника бухгалтеру.
Бухгалтер на підставі рахунку постачальника щоденно формує платіжне доручення на оплату і передає платіжне доручення у банк.
Бухгалтер на підставі виписки з розрахункового рахунку банка робить відмітку про оплату рахунку у реєстрі рахунків постачальників.
Менеджер відділу закупок при надходженні товару і (або) при сплаті робить запис у Журналі надходжень і оплат.
Бухгалтер в кінці кожного місяця виводить сальдо взаєморозрахунків з клієнтами.
Висновок
Отже, метою початкових етапів створення ІС, виконуваних на стадії аналізу діяльності організації, є формування вимог до ІС, коректно і мети, що точно відображають, і завдання організації-замовника. Щоб специфікувати процес створення ІС, що відповідає потребам організації, потрібно з'ясувати і чітко сформулювати, в чому полягають ці потреби. Для цього необхідно визначити вимоги замовників ІС і відобразити їх на мові моделей у вимоги до розробки проекту ІС так, щоб забезпечити відповідність цілям і завданням організації.
Завдання формування вимог до ІС є одній з найбільш відповідальних, таких, що важко формалізуються і найбільш дорогих і важких для виправлення у разі помилки. Сучасні інструментальні засоби і програмні продукти дозволяють достатньо швидко створювати ІС по готових вимогах. Але часто ці системи не задовольняють замовників, вимагають численних доопрацювань, що приводить до різкого дорожчання фактичної вартості ІС. Основною причиною такого положення є неправильне, неточне або неповне визначення вимог до ІС на етапі аналізу.
На етапі проектування перш за все формуються моделі даних. Проектувальники як початкова інформація отримують результати аналізу. Побудова логічної і фізичної моделей даних є основною частиною проектування бази даних. Отримана в процесі аналізу інформаційна модель спочатку перетвориться в логічну, а потім у фізичну модель даних.
Паралельно з проектуванням схеми бази даних виконується проектування процесів, щоб отримати специфікації (описи) всіх модулів ІС. Обидва ці процесу проектування тісно зв'язані, оскільки частина бизнес-логики зазвичай реалізується в базі даних (обмеження, трігери, процедури, що зберігаються). Головна мета проектування процесів полягає у відображенні функцій, отриманих на етапі аналізу, в модулі інформаційної системи. При проектуванні модулів визначають інтерфейси програм: розмітку меню, вид вікон, гарячі клавіші і пов'язані з ними виклики.
На етапі реалізації здійснюється створення програмного забезпечення системи, установка технічних засобів, розробка експлуатаційної документації.
Етап тестування зазвичай виявляється розподіленим в часі.
Після завершення розробки окремого модуля системи виконують автономний тест, який переслідує дві основну мету:
1. Виявлення відмов модуля (жорстких збоїв);
2. Відповідність модуля специфікації (наявність всіх необхідних функцій, відсутність зайвих функцій).
Останній тест інформаційної системи - приймально-здавальні випробування. Такий тест передбачає показ інформаційної системи замовникові і повинен містити групу тестів, що моделюють реальні бизнес-процессы, щоб показати відповідність реалізації вимогам замовника.
Необхідність контролювати процес створення ІС, гарантувати досягнення цілей розробки і дотримання різних обмежень (бюджетних, тимчасових і ін.) привело до широкого використання в цій сфері методів і засобів програмної інженерії: структурного аналізу, об'єктно-орієнтованого моделювання, CASE-систем.
Використана література:
С.А. Орлов «Технологи разработки програмного обеспечения» 2002 г.
А.В. Гаврилов «Системы искуственного интелекта» 2001 г.
Скотт Ф. Уилсон, Брюс Мейплс, Тим Лендгрейв «Принципы проетирования и обработки програмного обеспечения» 2002 г.
А.С. Гринберг, И.А. Король «Информационный менеджмент» 2003 г.
Карл И. Вигерс «Разработка требований к программному обеспечению» 2004 г.