База даних взаємовідносин з клієнтами станції технічного обслуговування автотранспорту

Размещено на http://www.allbest.ru/

ВСТУП

обслуговування автотранспорт база дані

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

Спочатку бізнес зростає за рахунок розширення виробництва та ринків збуту. При досягненні фізичних меж ринку збуту і неможливості подальшого розширення виробництва єдиним шляхом розвитку бізнесу є підвищення якості, що ми спостерігаємо з кінця 1980-х років з появою стандартів в галузі забезпечення якості (наприклад, ISO 9000 [1]). Однак, повсюдним впровадженням систем забезпечення якості створюємо ситуацію, коли всі конкуренти на ринку можуть запропонувати товар однакової якості. У цій ситуації актуальним стає філософія бізнесу, центром якої є клієнт. Такий підхід висловився в появі автоматизованих систем управління взаємовідносинами з клієнтами (УВК) або CRM (Customer relationship management).

Безумовно створення CRM систем не можливе без наявності БД обліку інформації про об'єкти бізнесу, персонал, замовників, замовлень і руху матеріальних ресурсів тощо.

Таким чином CRM-системи стають результатом розвитку автоматизованих систем (АС) та БД, які забезпечують успішний розвиток бізнесу за рахунок покращення якості обслуговування кінцевого користувача.

Впровадження АС на будь-якому підприємстві дає змогу:

автоматизація як підвищення продуктивності праці;

підвищення якості обслуговування та ефективності бізнесу;

отримання конкурентних переваг за рахунок автоматизації;

CRM (Customer Relationship Management).

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

Об'єктом дослідження є облік технічного обслуговування автотранспорту.

Предметом дослідження є база даних обліку технічного обслуговування автотранспорту.

Для досягнення мети у роботі вирішуються наступні завдання:

вивчення предметної області;

вибір ефективного життєвого циклу (ЖЦ) створення системи;

проектування бази даних та інтерфейсу користувача;

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

здійснити практичне випробування.

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

ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ

Система управління взаємовідносинами з клієнтами CRM

Система управління взаємовідносинами з клієнтами (Customer relationship management, CRM) -- прикладне програмне забезпечення для організацій, призначене для автоматизації стратегій взаємодії з клієнтами, зокрема, для підвищення рівня продажів, оптимізації маркетингу і поліпшення обслуговування клієнтів шляхом збереження інформації про клієнтів та історії взаємовідносин з ними, встановлення і поліпшення бізнес-процедур і подальшого аналізу результатів [2].

CRM Ї модель взаємодії, центром всієї філософії бізнесу є клієнт, а основними напрямами діяльності є заходи з підтримки ефективного маркетингу, продажів та обслуговування клієнтів. Підтримка цих бізнес-цілей включає збір, збереження та аналіз інформації про споживачів, постачальників, партнерів, а також про внутрішні процеси компанії. Функції для підтримки цих бізнес-цілей включають продажу, маркетинг, підтримку споживачів [3].

До 1993 року ринок CRM складався з двох основних напрямків -- автоматизації торгових представників (Sales Force Automation -- SFA) [4] та клієнтського обслуговування (Customer Service -- CS). Первинні призначення автоматизованих систем управління територіальними продажами полягало в тому, щоб торгові представники могли управляти «точками дотику» своїх клієнтів, а також працювати з планом продаж, узгодженим із календарем. З часом подібні системи збагатилися впровадженням функції управління можливостями, що на практиці означало підтримку тактики та методології продаж, прийнятої в компанії, а також можливість взаємозв'язку з іншими підрозділами компанії, наприклад, із службою клієнтської підтримки чи сервісними службами. До 2000 року CRM-системи, як правило, були «однобокими» -- так звані «менеджери контактів», системи підтримки маркетингових заходів чи системи для автоматизації сервісних служб.

В період з 2000 по 2005 роки почав формуватися спільний бізнес компаній із споживачами (Colaborative Commerce -- спільна комерція). Спільна комерція характеризується налагоджуванням інтерактивної взаємодії компаній з їхніми постійними партнерами через Інтернет. Така взаємодія передбачає надання зовнішнім користувачам значно ширшого доступу до корпоративної інформації у зв'язку з чим повинна базуватися на принципах гарантії безпеки та довіри до партнера а також на узгоджених правилах роботи.

Після 2005 року наступила друга хвиля Colaborative Commerce, що базується на більшій відкритості ERP-систем (Enterprise Resource Planning, планування ресурсів підприємства). Провідні виробники стали створювати користувацькі інтерфейси для своїх ERP-систем, [5] з'явилися електронні торгівельні площадки B2С (Business-to-Consumer), формується нова інфраструктура ведення бізнесу. У цьому випадку, на відміну від першої хвилі, мова іде про взаємодію «багато до багатьох», -- підприємства співпрацюють не тільки з постійними партнерами, а й з усіма членами бізнес-суспільства. Практично усі сучасні CRM-системи отримали в більшій чи меншій мірі вказані вище можливості, рівні обробки та надання інформації -- обробка і зберігання даних в колективних сховищах, розробка баз знань, Інтернет-засоби для інтерактивної взаємодії з клієнтом засобами корпоративних порталів.

Призначення та особливості СRM-систем

Інформаційними системами, що забезпечують ефективну орієнтацію на ринок, в даний момент є системи класу CRM -- сучасний напрям у сфері автоматизації корпоративного управління. Дані системи спрямовані на створення великої бази «вірних» клієнтів, яка як раз і є для підприємства довгостроковою конкурентною перевагою. Такі системи з'явилися в середині 90-х років. і знаходяться в стадії розвитку, тому на українському ринку вони представлені набагато меншою мірою, ніж системи ERP [6]. На початку 90-х років, коли CRM ще не оформилася як єдина концепція, вже існував набір «цеглинок», які формують систему обслуговування клієнтів. У складі такої системної структури виділяють:

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

ряд маркетингових БД, які забезпечують аналіз на рівні продукту (його продажу), але слабо інтегрованих з джерелами іншої інформації;

системи доставки інформації до клієнта (пряма поштова розсилка і т. д.);

базові аналітичні інструменти, використовувані для аналізу поведінки покупця при дискретній купівлі, але без урахування його ЖЦ [7].

Лише в 90-ті роки всі зазначені системи були інтегровані в одне ціле в рамках концепції CRM.

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

Існує три CRM-підходи, кожний з яких може бути реалізованим окремо від інших:

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

співробітницький -- програма взаємодіє зі споживачами без участі персоналу з роботи з клієнтами;

аналітичний -- аналіз інформації про споживачів із різноманітними цілями;

CRM-система може включати в себе (рис. 1.1):

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

операційну частину, що забезпечує авторизацію операцій та оперативну звітність;

сховище даних;

аналітичну підсистему;

розподілену систему підтримки продажів.

Рисунок 1.1 - Компоненти CRM-системи

Принципи CRM-систем:

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

синхронізація управління множинними каналами взаємодії;

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

Основні можливості CRM-систем [8]:

управління бізнес-процесами -- дозволяє автоматизувати послідовні операції, які виконуються співробітниками організації;

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

планування та управління продажами -- СRМ дозволяє складати плани за різними показниками: дохід з продажу по менеджерам, відділам, продуктам. По історії проектів можна відбудувати воронку продажів, що дозволяє визначати проблемні зони в циклах продажів. Планування і контроль виконання плану по факту. Є можливість ведення різних прайс-листів (оптових, дрібнооптових, роздрібних), враховувати акційні пропозиції, знижки від обсягу покупки. Вся робота з клієнтом відбувається в одній системі: планування заходів, здійснення угод, підготовка і виписка необхідних звітних документів;

планування та управління закупівлями і доставками -- в системі менеджери завжди можуть бачити наявність і кількість товарів на складі. Відповідальні співробітники можуть стежити за виконанням плану закупівель;

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

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

можливість роботи по мережі;

імпорт контрагентів з інших баз;

легкість і швидкість у навчанні роботи з системою.

Класифікація CRM-систем

Більшість існуючих CRM-систем народилися з систем, які давно автоматизували певні принципи взаємодії з клієнтами. Більшість з поточних CRM-систем -- це старі системи SFA, SMS (Sales & Marketing System -- система інформації продажу та маркетингу), CSS (Customer Support System -- система обслуговування клієнтів) і їм подібні, в які додано трохи нових полів та змінено назву і позиціонування. Раніше (приблизно до 2000 року) CRM-системи, як правило, були «однобокі» (так звані «менеджери контактів», або системи підтримки маркетингових заходів, або системи для автоматизації сервісних служб). Однак до 2006 року практично всі сучасні CRM-системи отримали в більшій чи меншій мірі всі зазначені можливості та рівні обробки інформації [9].

Класифікація за функціональними можливостями:

управління продажами;

управління маркетингом;

управління клієнтським обслуговуванням.

Існує безліч класифікацій CRM-систем. Однією з найпоширеніших класифікацій є поділ сучасних CRM-систем за рівнями обробки інформації і завданням, які вирішуються компаніями в ході використання CRM, на три ключових напрямки [10] які представлені у табл. 1.1.

Класифікують можливості (модулі) CRM-систем за функціональністю та рівнем обробки інформації. За функціональністю можна згрупувати блоки процесів: маркетинг, обробка заявок та побажань, продажі, сервісне обслуговування. В якості окремих складових зазвичай виділяють [11]:

call-центри -- центри обробки вхідних викликів. Спочатку це були телефонні дзвінки, а останнім часом сюди почали включати усі канали взаємодії;

функції (модулі) обробки інформації:

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

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

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

Таблиця 1.1

Класифікація CRM-систем щодо цільового використання

Цільове використання	Призначення	Приклади реалізації
Оперативне	Забезпечення оперативного доступу до інформації у ході контакту з клієнтом в процесі продажу та обслуговування. Охоплює маркетинг, продажі і сервіс	Для малих підприємств: ACT, GoldMine, Maximaizer, Sales Expert, Конс-Маркетннг. Для середніх: Clientele. Onyx. Sales Logix. Для великих: Oracle, SAP, Siebel, BAAN, «Управління діловими процесами. Парус-Клієнт»
Аналітичне	Спільний аналіз даних, що характеризують діяльність клієнта і фірми. Отримання нових знань, висновків, рекомендацій і т. д. Використовує складні математичні моделі для пошуку статистичних закономірностей і вибору найефективнішої стратегії маркетингу, продажів, обслуговування клієнтів	Brio, Business Objects, Broadbasc, E.Piphany, Hyperion, MicroStrategy, SAS. Marketing analytic
Колябораційне	Забезпечує безпосередню участь клієнта в діяльності фірми і можливість впливати на процеси розробки продукту, його виробництво, сервісне обслуговування	IntraNet Solutions, Plumtree, Symon, Vignette, Aspect, Broadvision, Cisco

Серед відомих CRM-систем, які встановлюються і обслуговуються в Україні є такі СRM-системи, як: SAP-CRM, Microsoft Dynamics CRM, Shugar-CRM, Vtiger CRM та інші.

Дослідник проблем управління взаємовідносин з клієнтами Джилл Діше [12] виділяє чотири категорії провадження CRM-системи у діяльність підприємств, в залежності від рівня складності:

CRM -- проект розрахований на один підрозділ підприємства, який реалізується за допомогою внутрішніх ресурсів підприємства;

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

CRM-система як єдина функція підприємства для виконання бізнес-завдання, з можливістю використання додатково залучених ресурсів;

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

Згідно з [13], основні галузі бізнесу, в яких можна застосувати CRM-системи представлені на рис. 1.2.

Рисунок 1.2 -- Основні галузі бізнесу, в яких можна застосувати CRM-системи

У банках CRM вирішує чотири основні проблеми [14]. По-перше, це стандартизація процесів обслуговування клієнтів. По-друге, управління персоналом банку. Це важливо, оскільки саме в банківській сфері дуже багато залежить від взаємодії клієнт-співробітник, і в разі звільнення когось із персоналу, співробітник може переманити за собою клієнта. По-третє, дозвіл внутрішньої конкуренції між підрозділами. Четверта задача, спільна для всіх систем, упорядкування інформації про клієнтів.

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

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

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

Структурована БД дозволяє компаніям телекомунікаційних провайдерів оперативно реагувати на всі запити, швидко і якісно обробляти замовлення. Моніторинг заявок здійснюється в технічному департаменті. Це дає клієнту можливість доступу до актуальної інформації про послуги компанії, а також стан і термін виконання його заявки.

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

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

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

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

Спрямованість виробничих процесів визначається станом ринку [17]. CRM-рішення дозволяють проводити глибокий аналіз відповідності попиту та пропозицій для вироблення правильної виробничої тактики. Система дає можливість автоматизувати рутинні процеси, такі як підготовка комерційних пропозицій, специфікацій, оформлення договорів і так далі.

Клієнт ЗМІ (засоби масової інформації) може виконувати різні ролі: експерта, рекламодавця, читача чи слухача. Завданням компанії є правильно ранжувати клієнтів, щоб отримати від взаємодії з клієнтами найбільшу вигоду [18].

Для компанії, що постачають ІТ-послуги, важливо встановити тривалі продуктивні зв'язки з кожним клієнтом. Робота над проектом може бути колективною, тому важливо за допомогою CRM-системи об'єднати діяльність кількох підрозділів, наприклад, комерційних і технічних служб. Таким чином, очевидно, що якісні CRM-системи потрібні в будь-якій сфері бізнесу [19].

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

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

Система керування базами даних

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

Основні характеристики СКБД:

контроль за надлишковістю даних;

несуперечливість даних;

підтримка цілісності БД (коректність та несуперечливість);

цілісність описується за допомогою обмежень;

незалежність прикладних програм від даних;

спільне використання даних;

підвищений рівень безпеки.

Можливості СКБД:

дозволяється створювати БД (здійснюється за допомогою мови визначення даних DDL (Data Definition Language) [20];

дозволяється додавання, оновлення, видалення та читання інформації з БД (за допомогою мови маніпулювання даними DML (Data Manipulation Language), яку часто називають мовою запитів [21]);

можна надавати контрольований доступ до БД за допомогою:

системи забезпечення захисту, що запобігає несанкціонованому доступу до БД;

системи керування паралельною роботою прикладних програм, що контролює процеси спільного доступу до БД;

система відновлення, що дозволяє відновлювати БД до попереднього несуперечливого стану, який був порушений в результаті збою апаратного або програмного забезпечення.

Можна виділити деякі з багатьох СКБД, які представлені в табл. 1.2.

Таблиця 1.2

Класифікація основних СКБД

Класифікація	Назва СКБД
Лідери ринку	MS SQL Server, Oracle Database, MySQL
Інші	Cache, CouchDB CUBRID, IMS DB2 Firebird, H2 Informix, Ingres, InterBase, MSDE, Mnesia MongoDB, Msql, , Pervasive SQL, PostgreSQL Redis, Sybase ASE, Sybase ASA, Sybase IQ, ЛИНТЕР, Microsoft Access

У світі існує багато різноманітних СКБД. Багато з них насправді є не закінченими продуктами, а спеціалізованими мовами програмування, за допомогою яких кожний, хто вивчить дану мову, може сам створювати такі структури, які йому потрібні, і вводити в них необхідні елементи управління [22].

Необхідність програмувати завжди утримувала устаткування БД в малому бізнесі. Великі підприємства могли дозволити собі зробити наказ на програмування спеціальної системи «під себе». Малим підприємствам звичайно не по силам було не тільки вирішити, але й правильно сформулювати цю задачу.

Становище покращилось з появою у складі пакета Microsoft Office системи керування базами даних Access [23]. За допомогою Access звичайні користувачі отримали зручний засіб для створення та експлуатації досить міцних БД без необхідності щось програмувати. У той же час робота з Access не викреслює можливості програмування. За бажанням систему можна розвивати та настроювати своїми силами.

Ще одним додатковим досягненням Access є інтегрованість цієї програми з Excel, Word та іншими програмами пакета Office. Данні, створені в різних додатках, утворюючих цей пакет, легко імпортуються та експортуються з одного додатка в інший.

Системи керування базами даних [24] є набором програмних засобів, необхідних для створення, використання і підтримки БД. Вона поєднує відомості з різних джерел в одній реляційній БД. Створювані форми, запити і звіти дозволяють швидко й ефективно обновляти дані, отримувати відповіді на питання, здійснювати пошук потрібних даних, аналізувати дані, друкувати звіти, діаграми і поштові наклейки.

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

Основне призначення СКБД -- створення та підтримка в актуальному стані БД, а також зв'язок її з програмами розв'язування економічних завдань (прикладні програми користувачів).

Різновиди систем керування базами даних, їх огляд

Системи керування даними першого покоління. СКБД першого покоління характерні тим, що кожна група користувачів розробляла своє власне програмне забезпечення по управлінню даними. Наслідками такої сепаратизації стало надмірне дублювання програмних кодів і даних [25].

Системи керування даними другого покоління. Файли взаємопов'язаних даних об'єднуються в бази даних. СКБД створюються для таких досвідчених користувачів, як програмісти.

Системи керування даними третього покоління. Можливості СКБД розширились. Створені розвинуті інтерфейси, що забезпечують інтерактивний доступ звичайним користувачам.

Переваги СКБД:

скорочення надлишку даних;

без БД неможливо уникнути зберігання надлишкових даних;

при наявності центрального контролю БД деякі надлишкові дані можна усунути;

Надлишкові дані не можуть бути повністю усунені, оскільки велику роль в СКБД відіграють питання часу і достовірності.

Проблеми автоматизації взаємовідносин з клієнтами станції технічного обслуговування автотранспорту

Як було сказано вище, спочатку бізнес зростає за рахунок розширення виробництва та ринків збуту. При досягненні фізичних меж ринку збуту і неможливості подальшого розширення виробництва єдиним шляхом розвитку бізнесу є підвищення якості, що ми спостерігаємо з кінця 1980-х років з появою стандартів в галузі забезпечення якості (наприклад, ISO 9000 [1]). Однак, повсюдним впровадженням систем забезпечення якості створюємо ситуацію, коли всі конкуренти на ринку можуть запропонувати товар однакової якості. У цій ситуації актуальним стає філософія бізнесу, центром якої є клієнт. Такий підхід висловився в появі автоматизованих систем CRM.

Безумовно створення CRM-систем не можливе без наявності БД обліку інформації про об'єкти бізнесу, персоналу, замовників, замовлень і руху матеріальних ресурсів.

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

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

У комп'ютерних програмах для СТО, спрямованих на оптимізацію менеджерської складової, для цих цілей необхідно реалізувати модуль для управління взаємовідносинами з клієнтами. Робота CRM-модуля в них заснована на основі сучасних інформаційних технологій, за допомогою яких СТО повинна мати можливість збирати і обробляти всю необхідну інформацію про своїх клієнтів та їх автомобілів на всіх стадіях життєвого циклу клієнта (залучення, утримання, лояльність), витягувати з клієнтської БД необхідну інформацію та історії технічного обслуговування автомобілів і використовувати цю інформацію в інтересах свого бізнесу шляхом вибудовування взаємовигідних відносин з клієнтами [26].

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

Які оптимальні шляхи взаємодії СТО з клієнтом?

Як досягти гарного враження клієнта, одержуваного ним від цієї взаємодії?

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

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

МОДЕЛЬ РЕАЛІЗАЦІЇ СИСТЕМИ ВЗАЄМОВІДНОСИН З КЛІЄНТАМИ

Вибір життєвого циклу рішення задач

Реалізація моделі системи взаємовідносин з клієнтами-споживачами послуг СТО -- комплексна задача яку ми пропонуємо реалізовувати за наступною методикою:

Огляд схем розробки ЖЦ рішення задач.

Огляд моделей ЖЦ для реалізації поставленої задачі.

Вибір найкращої моделі та визначення її основних етапів.

Основні поняття життєвого циклу розробки

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

Кожна система, незалежно від її типу та масштабу, проходить життєвий цикл відповідно до деякої інструкції від свого початкового задуму до остаточного припинення використання. Просування системи по частинах цієї інструкції, в якій би то не було послідовності та яким би то не було чином, називається життєвим циклом системи [27]. Опис ЖЦ, таким чином, -- це концептуальна сегментація визначення потреби в системі, її реалізації у вигляді продукції або послуги і її використання, еволюції та виведення з експлуатації. Опис ЖЦ зазвичай сегментовано по фазах, які складаються з однієї або декількох задач, в результаті виконання яких досягається один або декілька основних результатів [28]. Поділ на фази сприяє плануванню, розгортанню, експлуатації та підтримки цільової АС.

На рис. 2.1 представлена узагальнена схема процесу розробки ЖЦ програмного забезпечення.

Рисунок 2.1. Узагальнена схема процесу розробки

Стадії ЖЦ системи можуть повторюватися ітераційним чином у зв'язку з поступовим уточненням вимог до системи та/або з необхідністю її адаптації до тих змін, які виникають в предметній області системи. Такий цикл проходять всі технічні, технологічні та інші інформаційні системи і в кожному випадку вони повинні бути економічно обґрунтовані і прив'язані до конкретних умов виробництва [29]. Основною причиною застосування описів життєвого циклу є потреба в прийнятті рішень за певними критеріями до переходу процесу розробки на наступну стадію АС.

Сучасні моделі життєвих циклів

Каскадна модель. Каскадна модель демонструє класичний підхід до розробки різноманітних систем в будь-яких прикладних областях. Вона передбачує послідовну організацію робіт, де головною особливістю є розбиття всього процесу розробки на етапи, причому перехід з одного етапу на інший здійснюється тільки в тому випадку, коли всі роботи на попередньому кроці були завершені (рис. 2.2) [30].

З плином часу стадії каскадної моделі не раз видозмінювались, але все ж можна виділити шість основних етапів розробки:

Рисунок 2.2. Каскадна модель ЖЦ розробки

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

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

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

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

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

Останній етап -- супровід готового проекту. Даний етап включає в себе існування програмного продукту. Головне завдання цього етапу -- переконати замовника, що всі його вимоги виконані повною мірою[31].

Нижче представлений реальний процес розробки по каскадній моделі (рис. 2.3).

Рис. 2.3 -- Реальний процес розробки по каскадній моделі

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

Спіральна модель. В рамках даної моделі розробки АС (рис. 2.4) вибудовується наступна спіральна послідовність: аналіз вимог -- проектування -- реалізація -- тестування. Така послідовність виконується неодноразово. Основними причинами повторювань виступають необхідність попередження ризиків та представлення Замовнику часткову версію проекту для отримання відкликів та побажань. Якщо розроблювана система достатньо складна, то треба виконувати проміжкові ітерації, не відкладаючи цю фазу на кінець, як це передбачає каскадна модель [32].

Рисунок 2.4 -- Спіральна модель ЖЦ розробки

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

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

V-подібна модель. V-подібна модель була створена з метою допомогти команді, що працює над проектом, в плануванні із забезпеченням подальшої можливості тестування системи [33].

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

Рисунок 2.5 - V-подібна модель ЖЦ розробки

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

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

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

Модель Microsoft Solution Framework (MSF). Модель процесів MSF являє загальну методологію розробки до впровадження новітніх інформаційних технологій. Особливість цієї моделі полягає в тому, що завдяки своїй гнучкості та відсутності жорсткої прив'язки процедур вона може бути застосована при розробці досить широкого кола IT проектів. Ця модель поєднує в собі властивості двох стандартних моделей ЖЦ розробки: каскадної і спіральної.

Процес MSF орієнтований на «віхи» -- ключові точки проекту, що характеризують досягнення в його рамках будь-якого істотного (проміжного або кінцевого) результату (рис. 2.6).

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

Модель MSF найчастіше застосовується до процесу розробки традиційного ПЗ, але також вона може бути використана для розробки і впровадження рішень в області електронної комерції та інших складних ІС, які можуть виникнути в майбутньому [35].

Рисунок 2.6 -- Модель MSF життєвого циклу розробки

Модель прототипування. В основі моделі прототипування [36] лежить ідея побудови експериментальної (прототипної) системи, на модифікаціях якої ітеративно і швидко відпрацьовуються вимоги до проектованого продукту. Така модель зазвичай носить назву структурної еволюційної моделі швидкого прототипування і зображена на рис. 2.7:

Рисунок 2.7 - Модель прототипування життєвого циклу розборки

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

Замовники (кінцеві користувачі) системи аналізують наданий прототип і видають свої зауваження до тих пір, поки прототип не буде задовольняти всім їхнім вимогам. Після завершення процесу визначення вимог (шляхом розробки прискорених прототипів) формується детальний проект системи, а на основі прототипу створюється кінцевий робочий продукт [37, 38, 39].

Переваги використання моделі швидкого прототипування виявляються найбільш виразно при розробці таких АС, для яких немає аналогів, або у випадку, коли:

всі вимоги заздалегідь не відомі;

алгоритми або інтерфейси ускладнені;

вимоги не постійні або можуть бути невірно роз'яснені або невдало сформульовані;

слід уточнити вимоги;

існує потреба в розробці користувальницьких інтерфейсів;

потрібна перевірка концепції;

здійснюються тимчасові демонстрації;

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

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

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

вимоги схильні швидких змін, коли замовник неохоче погоджується на фіксований набір вимог або якщо про прикладну програму відсутнє чітке уявлення;

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

потрібно продемонструвати технічну здійсненність, коли технічний ризик високий;

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

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

прототипування завжди слід використовувати разом з елементами аналізу і проектування [40].

Обгрунтування вибору моделі прототипування для створення бази даних станції технічного обслуговування

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

При використанні структурної еволюційної моделі швидкого прототипування для прийнятного проекту проявляються такі переваги:

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

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

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

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

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

документація сконцентрована на кінцевому продукті, а не на його розробці;

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

На основі аналізу моделей ЖЦ була побудована табл. 2.1 для порівняння найбільшої кількості переваг для потреб даного проекту.

Таблиця 2.1

Порівняння моделей ЖЦ для потреб даного проекту

Потреби	Каскадна	V-подібна	Спіральна	Прототипування
Чи часто потреби будуть змінюватись у циклі?	Ні	Ні	Так	Так
Чи потрібно демонструвати потреби з метою визначення?	Ні	НІ	Так	Так
Чи буде проект ідентифікувати новий напрям продукту для організації?	Ні	Ні	Так	Так
Чи буде система змынюватись можливо, з використанням непередбачуваних методів на етапі супроводження	Ні	Ні	Так	Так
Чи є достатніми ресурси (час, гроші, персонал)?	Ні	Ні	Так	Так
Чи будуть користувачі ознайомлені з проблемами предметної області?	Ні	Ні	Ні	Так

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

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

ПРАКТИЧНА РЕАЛІЗАЦІЯ БАЗИ ДАНИХ

План проекту

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

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

Діаграма Ганта (англ. Gantt chart, також стрічкова діаграма, графік Ганта) -- це популярний тип діаграм, який використовується для ілюстрації плану, графіка робіт за будь-яким проектом. Є одним з методів планування та управління проектами [41].

Структура декомпозиції робіт (WBS) має такі характеристики [42]:

Описує з необхідною точністю зміст робіт за проектом;

Визначає весь обсяг робіт за проектом;

Формується у вигляді ієрархічної структури (проект декомпозирується на пакети/субпакети і т. д. робіт).

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

Має об'єктивний або вимірний результат, який розглядається як результат роботи по пакету або сукупність результатів робіт.

Microsoft Project -- система управління проектами, розроблена корпорацією Microsoft. Microsoft Project створений, щоб допомогти менеджерові проекту в розробці планів, розподілі ресурсів за завданнями, відстежуванні прогресу і аналізі обсягів робіт [43].

Задача плану проекту Ї в деталізації етапів ЖЦ у формальному документі. Побудова календарного плану починається зі структури поопераційної розбивки робіт або WBS (Work Breakdown Strukture, структура декомпозиції робіт). Для даного дипломного проекту розпишемо примірний план створення проекту, який представлений на рис. 3.1.



Рисунок 3.1 -- Календарний план дипломного проекту

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

Швидкий аналіз

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

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

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

У відповідності з класичним уявленням архітектури CRM зплануємо схему системи «БД CRM-СТО» (рис. 3.2).

Рисунок 3.2 -- Схема системи «БД CRM-СТО»

Центральним об'єктом даної системи є БД.

Перш ніж створювати таблиці, форми та інші об'єкти необхідно задати структуру БД. Хороша структура БД є основою для створення адекватної вимогам, ефективної БД.

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

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

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

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

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

...