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

Можливості підсистеми:

• Створення календарних планів для великої кількості об'єктів будівництва. Розгляд всіх об'єктів будівництва у межах організації, проекту.
• Створення кількох сценаріїв виконання одного проекту для вибору найбільш оптимального.
• Розрахунок календарних планів традиційними способами.
• Планування як "згори донизу", так і "знизу догори".
• Визначення планової собівартості будівництва.
• Призначення безпосередніх виконавців - працівників організації до виконання запланованих работ.
• Створення шаблонів робіт, груп робіт або цілих проектів для спрощення внесення даних.
• Ведення обліку фактичного виконання календарного плану (формування КС-2).
• Формування потреб та заявок у матеріально-технічних ресурсах.
• Облік фактично витрачених матеріалів, у розрізі робіт та всього об'єкта будівництва.
• Відображення інформації про плани робіт у графічному вигляді, як у діаграмі Гантта, так і у мережній діаграмі.
• Побудова графіків роботи ресурсів у розрізі робіт та об'єкта будівництва.
• Побудова графіків використання у роботах матеріалів у розрізі робіт та об'єкта будівництва.
• Формування тижнево-добових графіків робіт за будь-який час.
• Побудова звіту щодо виконання календарного плану робіт з аналізом ходу та прогнозуванням строків подальшого виконання робіт.
• Проведення оптимізації за ресурсами, що у деяких випадках, може суттєво скоротити час будівництва.
• Побудова графіка руху робочої сили в.
• Заповнення календарних планів будівництва на основі кошторисів, що ведуть у кошторисній підсистемі даної конфігурації та проектів, що ведуть у MS Project

Управління автотранспортом та будівельними машинами

• Оформлення заявок на використання машин та механізмів, відстеження статусу виконання заявки.
• Автоматичне формування наступних дорожніх листів та їх друк: Шляховий лист легкового автомобіля (Форма №3); Дорожній лист спеціального автомобіля (Форма №3 спец.); Дорожній лист легкового таксі (Форма №4); Дорожній лист вантажного автомобіля (Форма №4-п); Дорожній лист вантажного автомобіля (Форма №4-с); Дорожній лист автобуса (Форма №6); Дорожній лист автобуса незагального користування (Форма №6 спец.); Дорожній лист будівельної машини (Форма №ЕСМ-2).
• Автоматичне формування рапорту про роботу баштового крана (Форма ЕММ-1).
• Розрахунок нормованої витрати палива.
• Розрахунок вироблення машини (механізму) за різними параметрами.
• Облік ПММ та запчастин.
• Оформлення замовлень на обслуговування машин та механізмів, відстеження статусу виконання замовлення.
• Планування технічних обслуговувань та ремонтів машин (механізмів), складання план-графіків технічного обслуговування та ремонту.
• Облік технічного обслуговування та ремонту машин (механізмів).
• Накопичення та зберігання інформації про машину (механізм) та історію її (його) використання.
• Накопичення та зберігання інформації про встановлені вузли та агрегати.
• Накопичення та зберігання інформації про реєстраційні документи машин (механізмів) та водіїв (машиністів).

Управління фінансами

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

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

Бюджетування

Підсистема реалізує такі функції:

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

Управління грошима

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

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

Управління взаєморозрахунками

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

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

Основне призначення підсистеми взаєморозрахунків:

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

Бухгалтерський облік

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

• облік матеріалів у будівництві – акти на списання М-29, матеріальний звіт, невідфактуровані поставки, система розподілу відхилень;
• галузева система збору витрат основного виробництва (власні сили та субпідрядні роботи), допоміжних виробництв, витрат на експлуатацію будівельних машин та механізмів, накладних витрат;
• облік виконання робіт КС-3, облік придбання робіт субпідрядників, облік послуг генпідрядника та послуг замовника;
• облік внутрішньогосподарських розрахунків у філіальних структурах за широким спектром операцій;
• спеціалізовані звіти щодо розрахунків із замовниками та субпідрядниками по виконаних роботах;
• галузевий облік основних засобів, нарахування амортизації;
• облік фінансових результатів діяльності у розрізі об'єктів будівництва;
• можливість комплексного обліку фактів господарської діяльності диверсифікованих компаній – напрямів промислового виробництва, капітального будівництва, роботи будівельної техніки;
• облік матеріальних цінностей;
• операції з банку та каси;
• валютні операції;
• розрахунки з підзвітними особами;
• розрахунки з персоналом з праці;
• розрахунки із бюджетом.

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

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

Якість ведення бухгалтерського обліку контролюється спеціалізованим звітом "Аналіз стану бухгалтерського обліку", що дозволяє контролювати складні операції та оперативно визначати місця виникнення (до документа) небажаних відхилень.

Актуальність форм регламентованої звітності підтримується можливістю автоматичного поновлення через Інтернет.

Податковий облік

Податковий облік з податку прибуток у зміни ведеться незалежно від бухгалтерського обліку. Господарські операції відображаються паралельно у бухгалтерському та податковому обліку. Основу ведення бухгалтерського та податкового обліку складають розділені Плани рахунків, що мають "дзеркальне" кодування. Для цілей бухгалтерського та податкового обліку припустимо використання незалежних способів оцінки матеріально-виробничих запасів при списанні, способів обчислення амортизації тощо. Якість ведення податкового обліку контролюється звітом "Аналіз стану податкового обліку з податку на прибуток", що дозволяє у наочній формі контролювати величини податкових компонентів (НУ, ВР, ПР), розшифрування даних дається у спеціалізованих звітах. Забезпечено формування Декларації з податку прибуток.

Облік з податку додану вартість (ПДВ) реалізований відповідно до вимог глави 21 Податкового кодексу РФ, підтримується ведення "складного" ПДВ в умовах застосування різних ставок ПДВ (0%, 10%, 18%, без ПДВ), роздільного обліку за видами діяльності. Формуються Книга покупок та Книга продажів.

У зміни представлені заповнення всі форми декларацій з інших податках (транспортний податок, податку майно тощо.) і форм статотчетности.

Надсилання звітності через Інтернет

У цей додаток вбудований функціонал для роботи з сервісом "1С-Звітність", який дозволяє надсилати регламентовану звітність до контролюючих органів: ФНП, ПФР, ФСС, Росстат та Росалкогольрегулювання через Інтернет безпосередньо з програм 1С:Підприємства без перемикання на інші додатки та повторного заповнення форм .

Окрім здачі електронної звітності, сервіс "1С-Звітність" підтримує:

• Неформалізоване листування з ФНП, ПФР та Росстат;
• Звірки з податкової (запити ІОН);
• Звірки з ПФР (запити ІОС);
• Відправлення реєстрів лікарняних листів до ФСС;
• Отримання вимог та повідомлень;
• Надсилання електронних документів у відповідь на вимоги ФНП;
• Отримання виписок ЄДРЮЛ/ЄГРІП;
• Можливість формування пакетів зі звітністю у форматі для банків та інших одержувачів;
• Ретроконверсію (процес переведення ПФР паперового архіву в електронний вигляд;
• Надсилання повідомлень про контрольовані угоди;
• Онлайн-перевірку регламентованих звітів

Користувачам усіх версій, крім базових, для використання 1С-Звітності потрібна наявність чинного договору 1С:ІТС.

Без додаткової оплати підключити сервіс для однієї юридичної особи або ІП можуть користувачі, які уклали договір 1С: ІТС рівня ПРОФ.

Для підключення до сервісу «1С-Звітність» звертайтесь до своєї організації (партнеру фірми «1С»).

Пайове будівництво

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

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

Функціональні можливості підсистеми:

• Облік часток.
• Облік договорів із пайовиками (інвесторами).
• Зберігання інформації за договором.
• Облік вартості об'єкта будівництва та його часток.
• Облік платежів за договорами.
• Відстеження та контроль інвестицій за договорами інвестування.
• Контролює погашення платежів за договорами пайового будівництва.
• Формування звітів.

Управління експлуатацією об'єктів

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

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

В даний час основними можливостями підсистеми є:

• Розрахунок нарахувань з оплати житла та комунальних послуг за ставками та тарифами з урахуванням пільг, соціальних норм та субсидій.
• Облік та розрахунок за всіма видами послуг.
• Облік та розрахунок за загальнотериторіальними, загальноквартирними та індивідуальними приладами обліку.
• Друк сповіщень та квитанцій щодо нарахування квартплати.
• Облік платежів з оплати житлово-комунальних послуг.
• Коригування оплати за вже надані комунальні ресурси.
• Облік об'єктів оренди.
• Облік договорів оренди (укладення, додаткова угода, пролонгація, розірвання).
• Розрахунок орендної плати.
• Розрахунок платежів за спожиті комунальні ресурси.
• Розрахунок обсягу спожитих комунальних ресурсів орендарями та безпосередньо орендодавцем як за показаннями приладу обліку, так і площі, що пропорційно займається.
• Формування звітних даних.

Облік за міжнародними стандартами

Підсистема включає окремий План рахунків відповідно до МСФЗ, який може налаштовуватися користувачем, і забезпечує:

• трансляцію (перенесення) більшої частини облікових записів (проводок) із підсистеми бухгалтерського обліку (РСБУ) за правилами, які можуть гнучко налаштовуватися користувачем;
• паралельне ведення обліку за російськими та міжнародними стандартами за тими ділянками, де різницю між російськими нормативами і вимогами МСФЗ істотні (наприклад, облік основних засобів, нематеріальних активів);
• проведення власних регламентних документів (наприклад, нарахування витрат, облік резервів, облік знецінення активів та інших), а також внесення коригуючих записів у "ручному" режимі.

Можливості підсистеми дозволяють:

• мінімізувати трудомісткість ведення обліку за МСФЗ з допомогою використання даних російського обліку;
• проводити зіставлення даних російського обліку та обліку з МСФЗ, полегшуючи звіряння даних перед підготовкою звітності з МСФЗ.

Підсистема може бути налаштована для ведення обліку та складання фінансової звітності відповідно до зарубіжних стандартів, у тому числі US GAAP.

Управління персоналом

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

Підсистема призначена для інформаційної підтримки кадрової політики компанії та автоматизації розрахунків із персоналом. Серед можливостей підсистеми:

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

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

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

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

Розрахунок зарплати

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

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

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

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

Управління промисловим виробництвом

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

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

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

Реалізовані у підсистемі "Управління виробництвом" механізми планування виробництва забезпечують:

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

Планування виробництва

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

• за підрозділами та менеджерами;
• за проектами та підпроектами;
• за ключовими ресурсами;
• за номенклатурними групами та окремими номенклатурними одиницями.

Формування укрупненого плану виробництва

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

Планування потреб у ресурсах

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

Змінне планування виробництва

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

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

Формування позмінного плану виробництва

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

Визначення доступних потужностей ресурсів

• Ведення списку робочих центрів та технологічних операцій.
• Підтримка календарів доступності окремих робочих центрів та введення доступності ресурсів за даними календарів.
• Об'єднання робочих центрів у групи із завданням пріоритетів для планування.
• Розрахунок завантаження робочих центрів під час визначення графіка потреб у матеріалах.

Контроль виконання

• Формування плану-графіка потреб виробництва.
• Формування завдань виробництва, змінно-добових завдань.
• План-фактний аналіз ходу виробництва, контроль та аналіз відхилень.

Управління даними про вироби

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

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

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

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

Нормативний склад продукції використовується:

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

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

Управління витратами та розрахунок собівартості

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

Основні функції підсистеми:

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

Управління основними засобами

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

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

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

Керування продажами

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

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

Підсистема призначена для планування:

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

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

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

Планування може вестися з тимчасовою деталізацією від дня до року, що дозволяє:

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

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

Усі етапи проходження замовлення та його коригування фіксуються у системі відповідними документами. Менеджер може будь-якої миті:

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

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

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

Основні функціональні можливості підсистеми:

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

Управління закупівлями

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

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

Серед можливостей, які надає підсистема:

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

Управління складом (запасами)

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

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

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

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

Управління роздрібною торгівлею та підключення торгового обладнання

Для виробничих підприємств, які мають власні магазини та роздрібні торгові точки, у конфігурації передбачені можливості управління роздрібною торгівлею. Роздрібна торгівля може здійснюватися з будь-якого зі складів - оптової, роздрібної або неавтоматизованої торгової точки. Облік товарів у неавтоматизованих торгових точках ведеться за фіксованими роздрібними цінами. Реалізовано можливість підключення торговельного обладнання: сканери, термінали збору даних, дисплеї покупця, електронні ваги, ККМ у режимах "фіскальний реєстратор", "off-line" та "on-line". Система дозволяє проводити оцінку вартісних запасів у роздрібних цінах, порівнювати обсяги та прибутковість продажів у різних магазинах (торгових точках), контролювати правильність надходження виручки від магазинів та торгових точок.

Управління відносинами з покупцями та постачальниками

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

Підсистема "Управління відносинами з покупцями та постачальниками" дозволяє підприємству:

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

Сегментування покупців з використанням інтегрованого ABC(XYZ)-аналізу дозволяє автоматично поділити клієнтів:

• на класи в залежності від частки клієнта у виручці або прибутку компанії: важливі (А-клас), середньої важливості (B-клас), низької важливості (С-клас);
• за статусами: потенційний, разовий, постійний, втрачений;
• за регулярністю закупівель: стабільні (X-клас), нерегулярні (Y-клас), епізодичні (Z-клас).

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

Контроль та оцінка роботи менеджерів

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

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

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

Інтегровані засоби роботи з електронною поштою

Кошти роботи з електронною поштою інтегровані в єдиний інформаційний простір системи. В результаті обробка електронної кореспонденції проводиться у тісному взаємозв'язку з іншими бізнес-процесами підприємства:

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

Моніторинг та аналіз діяльності підприємства

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

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

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

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

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

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

Технологічні переваги

Використання як платформа системи "1С:Підприємство 8.2" забезпечує ефективну роботу та надійне зберігання інформації при роботі великої кількості користувачів.

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

На платформі "1С:Підприємство 8.2" реалізовано новий клієнтський додаток - тонкий клієнт: він може підключатися за протоколами http або https, причому вся бізнес-логіка реалізується на сервері. Віддалені підрозділи можуть, використовуючи тонкого клієнта, підключатися через Інтернет і в режимі on-line працювати з інформаційною базою. Підвищується безпека та швидкість роботи.

На платформі "1С:Підприємство 8.2" реалізовано нову клієнтську програму - Web-клієнт: не вимагає встановлення на комп'ютер користувача жодних компонентів, дозволяє використовувати на робочих місцях користувачів операційні системи Windows та Linux. Не вимагає адміністрування на комп'ютерах користувачів. Забезпечує оперативний доступ до інформаційної бази для "мобільних" працівників.

Реалізовано спеціальний режим роботи клієнтських програм - режим низької швидкості з'єднання (наприклад, під час роботи через GPRS, dialup). Можна працювати у будь-якій точці, де немає постійного підключення до Інтернету.

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

• прав користувача;
• особливостей конкретного застосування;
• налаштувань, зроблених самим користувачем.

Можлива побудова індивідуального інтерфейсу для кожного користувача.

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

Масштабованість та продуктивність

Використання платформи "1С:Підприємство 8.2" забезпечує ефективну роботу та надійне зберігання інформації при роботі сотень користувачів. Сучасна трирівнева архітектура системи дає збереження високої продуктивності при значному зростанні навантаження на систему та обсягів оброблюваних даних. Висока стійкість до відмов досягається за рахунок резервування кластера серверів, а оптимізація швидкодії - за рахунок динамічного балансування навантаження між кластерами. Використання СУБД світових лідерів (MS SQL, IBM DB2, Oracle Database) дозволяє будувати високопродуктивні та надійні інформаційні системи.

Побудова територіально-розподілених систем

Універсальний механізм обміну даними у форматі XML призначений для створення територіально-розподілених систем на основі "1С:Підприємства 8", організації обміну даними з іншими інформаційними системами. В одному прикладному рішенні можна створити кілька незалежних схем обміну з різними системами. Підтримується як класична структура розподілених систем (типу " зірка " ), а й складніші багаторівневі структури типу "сніжинка".

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

Розвиток засобів інтеграції

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

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

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

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

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

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

Види запитів в інформаційній системі:

Отримати перелік будівельних управлінь та/або дільниць та їх керівників.

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

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

Отримати склад бригад, які працювали (працювали) на будівництві зазначеного об'єкта.

Отримати перелік будівельної техніки, наданої зазначеному будівельному управлінню.

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

Отримати графік та кошторис на будівництво зазначеного об'єкта.

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

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

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

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

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

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

Вступ 3

1. Автоматизація будівельних компаній 5

1.1.

Необхідність автоматизації 5

1.2.

Комплексна автоматизація будівельних компаній 10

Мінуси комплексної автоматизації 12

Плюси комплексної автоматизації 12

Мінуси комплексної автоматизації 13

Плюси комплексної автоматизації 13

1.3.

Рішення в галузі автоматизації 13

2. Короткий аналіз діяльності підприємства 23

3. Пропозиції з автоматизації процесу управління будівельною компанією 30

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

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

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

У будівельних компаніях широко застосовується інженерна системотехніка будівництва, а саме: автоматизовані системи управління будівництвом (АСУС), системи автоматизованого проектування (САПР), автоматизовані системи обробки даних та документації (АСОД) та інші, що сприяють підвищенню ефективності та якості управління.

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

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

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

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

1. Автоматизація будівельних компаній

1.1. Необхідність автоматизації

Необхідність автоматизації управління будівництвом було зрозуміло ще період використання великих ЕОМ, у роки. У СРСР ця проблема мала особливу актуальність через високу централізацію системи управління і великої кількості великих будівництв. Проблема вирішувалася шляхом формування спеціальної служби – автоматизованої системи управління будівництвом (АСУС). Сутність використання АСУС полягала у тому, що всіх рівнях управління між управляючим і керованим ланками з'являлося нове ланка - обчислювальний центр (ВЦ). Обчислювальні центри являли собою великі організації, оснащені великими ЕОМ (другого покоління - на напівпровідниках), з численним персоналом постачальників завдань, програмістів, операторів, кур'єрів зі своїм транспортом, телетайпним зв'язком. Вирішувалися різноманітні завдання, починаючи від "рутинних" (облік витрати та запасів різних ресурсів, нарахування заробітної плати тощо) і закінчуючи складними "оптимізаційними" завданнями, коли вибирався найбільш підходящий варіант організації будь-яких робіт.

На багатьох будівництвах (особливо в Москві) АСУС функціонували досить успішно, але загалом такі системи приживалися погано. В умовах "дефіцитної" економіки одержувані рішення оптимізованих завдань далеко не завжди виявлялися реалістичними, а великий обсяг документації, що роздруковується, зазвичай вивчався будівельниками погано. Керівники будівельного виробництва були готові до настільки сильної перебудові стилю своєї роботи. ВЦ добре використовувалися лише для вирішення завдань обліку – складання відомостей ресурсів, підрахунку заробітної плати тощо.

Швидкий розвиток комп'ютерної техніки в 90-х роках зробив непотрібним громіздкі ВЦ і автоматизація пішла іншим шляхом. Замість великих ЕОМ з'явилися численні персональні комп'ютери, що розмістилися в будівельних організаціях на столах бухгалтерів, інженерів виробничо-технічних відділів, постачальників, комірників, головного інженера і т.д.

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

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

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

Наприкінці 90-х автоматизація більшості будівельних організацій перебувала на описаному 2 етапі, тобто. на стадії використання окремих комп'ютерів та АРМів.

Недоліком автоматизації даного етапу стало недосконалість зв'язку між окремими АРМами і пов'язана з цим необхідність дублювання інформації при її "перекиданні" з одного комп'ютера на інший. З цієї причини подальшим етаном розвитку автоматизованих систем стало створення на базі розрізнених АРМ єдиної інформаційної системи підприємства, що охоплює всі основні сфери era діяльності. Для використання такої системи комп'ютери будівельної організації, інколи ж пов'язаних із нею сторонніх організацій повинні об'єднуватися в єдину комп'ютерну мережу. У цьому програмне забезпечення значно ускладнюється, як і ускладнюється сама апаратна частина, тобто. з'являється безліч додаткових пристроїв, пов'язаних із зберіганням і передачею інформації по різних каналах зв'язку. Виникаючі поточні завдання у сфері діяльності можуть вирішуватися з використанням: даних всієї інформаційної ( " корпоративної " ) системи. Засновані системи управління отримали назву корпоративних інформаційних систем (КІС). Іншими словами КІС - це єдина інформаційна система, що пов'язує, між собою керівництво організації, її структурні підрозділи, іноді і суміжні підприємства, допоміжні служби, що охоплює всі основні сфери діяльності -бухгалтерію, матеріально-технічне забезпечення, загальну технічну політику, поточні організаційні питання та і т.д. Це людино-машинна система, коли він виробнича, господарська і фінансова боку діяльності підприємства стають хіба що цілком " прозорими " , тобто. можна безперервно аналізувати всі результати, тенденції, становище на будівельному ринку, забезпечуючи цим найбільшу ефективність управління. У зарубіжній практиці приблизно такі функції виконують "системи управління ресурсами" ERP.

Як і САПР, такі системи містять безліч стандартних та спеціалізованих модулів, причому кожна конкретна система MOJKIST включатиме, залежно від вимог замовника, свої додаткові модулі та допускати їх подальше розширення. КІСи мають широкі можливості: вони можуть взаємодіяти з програмами САПР, в першу чергу з модулями САМ-і САЕ-систем методи обробки інформації в них включають виконання функцій текстових редакторів, електронних таблиць, баз даних і т.д. Модулі CAD-систем (графічні), характерні для САПРа, в системах управління мають менше значення, по більшу роль набувають модулі управління документообігом (PDM-системи). Для вирішення господарських завдань використовуються економіко-математичні моделі, насамперед різні моделі бізнес-процесів.

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

... БУДІВЕЛЬНИХ КОМПАНІЯХ 2.1 Характеристика проектної будівельної компанії«АК-Марал» 2.2 Система якості відповідно до ІСО 9000 2.2.1МС ІСО ... розробки, впровадження та функціонування систем менеджменту; - розробка... побудови, - автоматизаціїта нових...

Розробкаавтоматизованої системи Відділ кадрів засобами MS Access

Дипломна робота >> Інформатика

1.2 Дослідження стану процесів автоматизаціїВідділ кадрів 1.2.1 Інформаційні... 2.1 Теоретична модель ІС«Відділ кадрів» 2.1.1 ... для підприємств будівельноїсфері Загальний фонд... власної розробці, орієнтованої на потреби компанії. Також...

Автоматизаціясистеми бюджетування фінансової служби (2)

Реферат >> Фінанси

менеджменту. (Проектування фрагментів ІС). 3.2. Застосування методів системного... використовується в будівельних компаніях. По кожному будівельномуоб'єкту зазвичай... і трудомісткий період розробкипрограми; неможливість повної автоматизаціївсіх процесів...

Розробкаінформаційного забезпечення системи управління якістю інформаційних послуг

Реферат >> Інформатика

РОЗДІЛ ІІ. Розробкаінформаційного забезпечення СУЯ будівельної компанії.................................................... ........... 44 2.1 ... , призначена для автоматизаціїуправління внутрішньою нормативною... . ГОСТ Р ІСО 19011-2003 (ІСО 19011-2002) ...

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

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

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

Зміст

• 3. Пропозиції з автоматизації процесу управління будівельною компанією 30
• 2.2 Нормальні форми
• 2.5 Алгоритм синтезу
• 2.8 Створення схеми даних
• 2.9 Вибір засобів розробки
• 3. Розробка інформаційної системи
• 3.1 Режим користувача
• 3.2 Режим роботи інвестором
• 3.3 Режим роботи управителя
• 3.4 Режим роботи директором
• 4. Безпека та санітарно-гігієнічні умови праці на робочому місці користувача ПЕОМ
• 4.1 Характеристика санітарно-гігієнічних умов праці
• 4.2 Вентиляція
• 4.3 Розрахунок освітлювальної установки
• 4.4 Режим праці
• 4.5 Вимоги щодо організації робочого місця
• 4.6 Електрична безпека
• Висновки
• 5. Розрахунок економічної ефективності проекту
• 5.1 План маркетингу
• 5.2 Цілі, завдання та методи оцінки інвестицій
• 5.3 Вибір та опис розроблюваного та альтернативного варіантів
• 5.4 Розрахунок вкладень на етапі розробки та налагодження основного варіанта
• 5.5 Розрахунок вкладень на етапі розробки та налагодження альтернативного варіанта
• 5.6 Розрахунок вкладень за роками етапу експлуатації
• 5.7 Підсумкові показники техніко-економічної ефективності
• Висновки
• Висновок
• Додаток 1Скрипт створення БД вMYSQL

3. Пропозиції з автоматизації процесу управління будівельною компанією 30

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

p align="justify"> Комп'ютеризація будівництва в технічному плані означає створення автоматизованих робочих місць, оснащених засобами обчислювальної техніки. Складність розв'язуваних управлінських завдань змушує розвивати та використовувати в інвестиційно-будівельній діяльності процеси розробки та впровадження програм, що реалізують конкретні комп'ютерні технології на технічних засобах, що є в даний час. Комп'ютеризація будівництва підвищує рівень знань та навичок у середовищі керівників та виконавців, змушує управлінський персонал ефективно використовувати у своїй повсякденній діяльності наявні засоби обчислювальної техніки з програмним забезпеченням будівельного виробництва.

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

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

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

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

1. Проектування інформаційної системи

1.1 Сутність інформаційної системи

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

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

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

1.2 Функціональна специфікація

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

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

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

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

автоматизація інформаційна система користувача

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

Будівельники займаються будівництвом об'єкта під керівництвом Керівників. Кожен Будівельник має свою спеціальність.

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

1.3 Підходи до проектування ІВ

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

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

· Об'єктно-орієнтований підхід – використовує об'єктну декомпозицію. Система описується термінах об'єктів і зв'язків з-поміж них, а поведінка системи у термінах обміну з-поміж них.

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

З'явилася методологія структурного програмування. Основою даної методології є процедурна декомпозиція програмної системи та організація окремих модулів у вигляді сукупності виконуваних процедур.

У другій половині 80-х років з'явилася методологія об'єктно-орієнтованого програмування

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

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

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

У цьому дипломному проекті використовується методологія об'єктно-орієнтованого підходу для опису бізнес-процесів підприємства.

1.4 Уніфікована мова моделювання UML

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

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

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

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

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

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

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

Потреба як процес розробки обумовлює необхідність створення стандартних умовних позначень. Мова UML є саме такою системою позначень.

Попередні версії UML почали використовуватися в галузі створення програмного забезпечення, а на підставі відгуків споживачів проводилися суттєві доопрацювання. Багато корпорацій відчули, що мова UML може бути корисною для досягнення їх стратегічних цілей. Це призвело до виникнення консорціуму UML, до якого увійшли такі компанії, як DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational та інші. У 1997 році консорціум виробив першу версію UML і представив її на розгляд групі OMG (Object Management Group), відгукнувшись на її запит щодо подання пропозицій стандартної мови моделювання.

Після розширення консорціуму вийшла версія 1.1 мови UML, яку група OMG прийняла наприкінці 1997 року. Після цього OMG приступила до супроводу UML і випустила в 1998 дві його нові версії. Мова UML стала стандартом де-факто у галузі розробки програмного забезпечення. В даний час ця мова продовжує активно розвиватися

Мова UML призначена для вирішення наступних завдань:

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

o Забезпечити вихідні поняття мови UML можливістю розширення та спеціалізації для більш точного представлення моделей системи в ООАП (об'єктно-орієнтований аналіз та проектування) конкретної предметної галузі.

o Жодна з конструкцій мови UML не повинна залежати від особливостей її реалізації у відомих мовах програмування.

o Заохочувати розвиток ринку об'єктних інструментальних засобів.

o Здатність удосконалюватися.

o Інтегрувати в себе нові та найкращі досягнення практики

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

· Діаграма варіантів чи прецедентів використання (use case diagram)

· Діаграма класів (class diagram)

· Діаграми поведінки (behavior diagrams)

o Діаграма станів (statechart diagram)

o Діаграма діяльності (activity diagram)

· Діаграми взаємодії (interaction diagrams)

o Діаграма послідовності (sequence diagram)

o Діаграма кооперації (collaboration diagram)

· Діаграми реалізації (implementation diagrams)

o Діаграма компонентів (component diagram)

o Діаграма розгортання (deployment diagram)

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

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

1.5 CASE засіб Rational Rose

Rational Rose – потужний CASE-засіб для проектування програмних систем будь-якої складності. Однією з переваг цього програмного продукту буде можливість використання діаграм мовою UML. Можна сказати, що Rational Rose є графічним редактором UML діаграм

CASE-засіб Rational Rose з часу своєї появи зазнав серйозної еволюції і перетворився на сучасний і потужний засіб аналізу, моделювання та розробки програмних систем. Саме в Rational Rose 98/2000 мова UML стала базовою технологією візуалізації та розробки програм, що визначило популярність та стратегічну перспективність цього інструментарію.

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

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

· Скорочення час розробки;

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

· Поліпшення споживчих якостей створюваних програм;

· Здатність вести великі проекти або групу проектів;

· дозволяє бути мовою спілкування між різними розробниками.

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

1.6 Діаграма варіантів використання

Розробка даної діаграми має такі цілі:

· Визначити загальні межі та контекст моделюваної предметної області на початкових етапах проектування системи

· Сформулювати загальні вимоги до функціональної поведінки проектованої системи.

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

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

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

Кошти Rational Rose дозволяють для опису функціональної системи скористатися графічним редактором для побудови Use Case діаграм (сценаріїв). Опишемо основні елементи див. таблицю 1.1.

Рис 1.1 Діаграма прецедентів

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

Рис.1.2 Діаграма керівника

Діаграмистанів.

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

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

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

Зі станом можна пов'язувати такі дані: діяльність, вхідна дія, вихідна дія та подія.

Діяльність (activity) - це поведінка, що реалізується об'єктом, доки він у цьому стані. Діяльність зображують усередині самого стану; її позначення має передувати слово do (робити) та двокрапка.

Вхідна дія (entry action) - це поведінка, яка виконується, коли об'єкт переходить у цей стан. Вхідну дію також показують усередині стану, його позначення передують слово entry (вхід) та двокрапка.

Вихідна дія (exit action) подібна до вхідної. Однак воно здійснюється як складова частина процесу виходу з цього стану. Вихідну дію зображують усередині стану, його опису передують слово exit (вихід) та двокрапка.

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

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

Рис.1.3 Діаграма станів "Об'єкта будівництва"

Діаграмадіяльності

Виділено об'єкт, дані про який необхідно зберігати у базі даних.

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

Кошти Rational Rose дозволяють для опису функціональної системи скористатися графічним редактором для побудови Activity діаграм (діяльності).

Діаграми діяльностей краще використовувати у таких ситуаціях:

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

· Аналіз потоків робіт (workflow) у різних варіантах використання. Коли варіанти використання взаємодіють друг з одним, діаграми діяльностей є сильним засобом уявлення та аналізу їхньої поведінки.

Рис.1.4 Діаграма активності "Створення об'єкта"

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

Діаграми взаємодії

Діаграми взаємодії (interaction diagrams) описують поведінку взаємодіючих груп об'єктів. Кожна діаграма описує поведінку об'єктів лише одного прецеденту. На діаграмі зображуються об'єкти і ті повідомлення, якими обмінюються між собою. Визначають три типи повідомлень:

· Інформаційні (informative) - повідомлення, що забезпечують об'єкт-одержувач інформацією для оновлення його стану;

· Повідомлення - запити (interrogative) - повідомлення, що вимагають видачу інформації про об'єкт-одержувача;

· Імперативні (imperative) - повідомлення, що запитують у об'єкта-отримувача виконання дії.

Існує два види діаграм взаємодії:

· Послідовності (sequence diagrams);

· Кооперативні (collaboration diagrams).

На діаграмі послідовності об'єкт зображується у вигляді прямокутника на вершині пунктирної вертикальної лінії. Ця вертикальна лінія називається лінією життя (lifeline) об'єкта. Вона є фрагментом життєвого циклу об'єкта у процесі взаємодії.

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

Рис.1.5 Діаграма послідовності "Призначення будівельника на об'єкт"

Висновок по діаграмі: виділено об'єкти сутності (список користувачів, об'єкт, список будівельників) та граничні об'єкти – сторінки (вікно введення пароля, вікно поточного об'єкта).

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

Рис.1.6. Кооперативна діаграма "Призначення будівельника на об'єкт

Алгоритм роботи із системою через WEB-інтерфейс

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

Для проектування веб-сайту вживається діаграма класів.

Rational Rose містить Add In під назвою Web Modeler для проектування сайтів.

Послідовність дій під час створення Web програми:

ü Підключити Web Modeler за допомогою пункту меню Add In - Add In Manager - Web Modeler. У меню Tools з'явиться новий пункт Web Modeler

ü Змінити установки, прийняті за умовчанням Tools - Options - Notation - Default Language - Web Notation

Використовується спеціальний стереотип, що дозволяє виділяти html-сторінки. На основі створеної діаграми автоматично генерується пов'язані HTML-сторінки.

Рис.1.7 Алгоритм роботи з програмою

2. Проектування бази даних

2.1 Вимоги до бази даних

1) Мінімальна надмірність. Дані, які у пам'яті ЕОМ, можуть містити як корисну, і шкідливу надмірність. Шкідлива надмірність завжди має місце, коли кожен користувач змушений створювати для своїх додатків окремий набір даних. Якщо декільком користувачам були б одні й самі дані, всі вони повторювалися у кожному наборі. Таку надмірність часто називають неконтрольованою, оскільки про її існування окремі користувачі можуть і не підозрювати. До корисної надмірності можна віднести періодичні копії даних, що зберігаються в базі даних. Ця надмірність легко контролюється. Більше того, вона є необхідною, наприклад, для відновлення даних, зруйнованих при випадкових збоях у роботі ЕОМ. Таким чином, вимогу мінімальної надмірності слід розуміти як усунення шкідливої ​​(неконтрольованої) та зведення до мінімуму корисної (контрольованої) надмірності.

2) Цілісність даних. Цілісність даних полягає у підтримці правильності даних. Забезпечується відновленням даних після руйнування в результаті випадкових збоїв у роботі ЕОМ, а також усунення суперечливості даних, що полягає у появі різних екземплярів для тих самих атрибутів. Суперечливість може з'явитися при оновленні надлишкових даних, якщо оновлення буде виконано лише на частині даних.

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

4) Незалежність даних. Забезпечує можливість зміни структури баз даних без зміни прикладних програм користувачів. Розуміється у двох аспектах, а саме, як логічна та фізична незалежність.

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

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

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

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

2.2 Нормальні форми

Реляційна база даних, спроектована відповідно до концептуальної схеми, може мати ряд серйозних недоліків, наприклад, містити інформаційну надмірність, і (або) у процесі обробки даних можуть виникати різні аномалії. Щоб усунути ці недоліки, тобто. Створити базу даних "хорошої", необхідно привести всі відносини бази даних до "сильних" нормальних форм.

Нині відомо кілька нормальних форм. Перша нормальна форма (позначатимемо 1НФ), далі - у міру "посилення" - 2НФ, 3НФ, нормальна форма Бойса-Кодда (НФБК) та 4 НФ. Практика показує, що приведення БД хоча б до 3НФ дозволяє уникнути здебільшого майже всіх недоліків.

Перша нормальна форма (1НФ).

Відношення зі схемою R та безліччю функціональних залежностей F знаходиться в 1НФ, якщо будь-який екземпляр схеми R задовольняє наступним умовам:

кожен атрибут схеми має унікальне ім'я;

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

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

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

щодо не повинно бути кортежів, що повторюються.

Друга нормальна форма (2 НФ).

Відношення зі схемою R і безліччю функціональних залежностей F знаходиться у 2НФ, якщо воно знаходиться в 1НФ, і кожен неключовий атрибут функціонально повно залежить від будь-якого можливого первинного ключа схеми-відносини R.

Проте, схема зв'язку, що у 2 НФ, також має недоліки. Зокрема, множина залежностей, визначена на цій схемі, може містити транзитивні залежності, які можуть призводити до небажаних наслідків (аномалій видалення).

Третя нормальна форма (3 НФ).

Схема відносин R з безліччю функціональних залежностей F знаходиться в 3НФ, якщо воно знаходиться у 2 НФ, і кожен неключовий атрибут прямо, а не транзитивно залежить від будь-якого можливого ключа схеми відношення.

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

Нормальна форма Бойса Кодда (НФБК).

Нормальна форма Бойса-Кодда "сильніша", ніж третя нормальна форма. Схема відносин R з безліччю функціональних залежностей F знаходиться в НФБК, якщо ліва частина кожної залежності (ХА) F, де А Х є первинний або можливий первинний ключ.

Якщо ставлення перебуває у НФБК, воно перебуває й у третій нормальній формі, але з навпаки.

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

2.3 Нормалізація схем відносин

Для побудови реляційної реалізації концептуальної схеми БД, яка була хоча б у 3 НФ, можна використовувати два способи:

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

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

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

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

Складність алгоритму вища, ніж поліноміальна.

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

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

2.4 Інтеграція власних уявлень

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

Сутності	Директор	Керуючий	Інвестор
object (об'єкт нерухомості)
investor (інвестор)
investing (інвестування)
employee (співробітник)
material (матеріал)
delivery (постачання)
building (будівництво)

Інтегрованеподаннякористувачів,представленеввиглядідіаграми

2.5 Алгоритм синтезу

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

Результатом роботи алгоритму є схема автоматизованої системи управління у вигляді набору декомпозиційних підсхем (R1, R2,., Rp), що задовольняють наступним умовам.

Кожна підсхема Ri з БД повинна бути хоча б у ЗНФ щодо безлічі функціональних залежностей F і відповідно G.

Синтезована інформаційна система містить мінімальний набір декомпозиційних підсхем Ri, I == 1,., Р. Ця умова захищає інформаційну систему від надмірності.

Для будь-якого екземпляра r (БД), що задовольняє F, виконується співвідношення. Ця умова гарантує здійсненність якості з'єднання без втрат інформації.

Схема автоматизованої системи управління, що задовольняє умовам 1,2 та 3, називається повною схемою автоматизованої системи управління.

Розглянемо кроки алгоритму.

Крок1 . Будуємо розширене безліч F функціональних залежностей, що має наступну структуру залежностей:

F = ((X I -> Y I) | (X I -> Y I) F, Y I = X I + \ X I). Цей крок робиться з метою побудови надлишкового або умовно ненадлишкового покриття F, що дозволить певною мірою задовольнити умову 3. Повністю забезпечити умову 3 вдасться після введення в розгляд поняття еквівалентності функціональних залежностей на кроці 5.

Крок 2. Будуємо надлишкове покриття F, виключаючи з F у будь-якій послідовності зайві залежності.

Очевидно, це покриття не канонічне.

Крок3 . Якщо серед функціональних залежностей з F" немає залежності, що включає всі атрибути з U, то додаємо до F" тривіальну залежність U-> Ш.

Крок4 . Перетворюємо отримані нетривіальні залежності елементарному виду (без зайвих атрибутів у лівих частинах).

Залежність X I - > Y I є елементарною, якщо не існує таких наборів атрибутів X J X I , що (X j - > Y I ) . Якщо - існує, то залежність X I - > Y I замінюється залежністю (X J - > Y I).

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

Залежності X I - >Y I і X J - > Y J називатимемо еквівалентними, якщо

, тобто. мінімальний ранг має залежність, що містить усі атрибути з U, а якщо її немає, то - тривіальна залежність U - > Ш. Всім залежностям із одного класу еквівалентності призначаємо однаковий ранг. Незрівнянним залежностям ранги призначаємо довільно.

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

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

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

Безлічатрибутів:

U = (mNo, mName, mCost, count, oNo, oAddress, oType, oStoreys, oState, eNo, eName, ePost, eState, eSalary, sum, iNo, iName, iPhone)

Безлічфункціональнихзалежностей:

F = (mNo®mName, mNo®mCost, mName®mNo, mName®mCost,

(oNo, mNo) ®count,

oNo®oAddress, oNo®oType, oNo®oStoreys, oNo®eNo, oNo®oState, oNo®oCost

eNo®eName, eNo®ePost, eNo®eState, eSalary

iNo®iName, iNo®iPhone,

(iNo, oNo) ®sum )

Крок 1. Розширена множина функціональних залежностей:

mNo + =mNo, mName, mCost =>mNo® (mName, mCost)

mNo + =…=>mNo®…

(oNo, mNo) + = oNo, mNo, count => (oNo, mNo) ?®count

oNo + = oNo, oAddress, oType, oStoreys, oState, oCost, eNo => oNo® (oAddress, oType, oStoreys, eNo, oState, oCost)

oNo + =…=>oNo®…

eNo + = eNo, eName, ePost, eState, eSalary => eNo® (eName, ePost, eState, eSalary)

eNo + =…=>eNo®…

iNo + = iNo, iName, iPhone => iNo® (iName, iPhone)

iNo + =…=>iNo®…

(iNo, oNo) + =iNo, oNo, sum=> (iNo, oNo) ®sum

(mNo, oNo, iNo, eNo) + =mNo, mName, mCost, count, sum, oNo, oAddress, oType, oStoreys, iNo, iName, iPhone, eNo, eName, ePost, eState, eSalary, oState, oCost

=> (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary, oCost)

F= (mNo® (mName, mCost), mNo®…, (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, eNo, oState, oCost), oNo®…, eNo® (eName, ePost, eState, eSalary), eNo®…, iNo® (iName, iPhone), iNo®…, (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary) )

Крок 2. Надлишкове покриття

F"= (mNo® (mName, mCost), (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, oState, oCost, eNo), eNo® (eName, ePost, eState, eSalary), iNo® (iName , iPhone), (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary) )

Крок 3. Тривіальна залежність

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

Крок 4. Елементарний вид залежностей

Усі залежності елементарні.

Крок 5. Еквівалентність залежностей

Еквівалентних залежностей немає.

Крок 6. Ранжування залежностей

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

Залежно X I Y I і X J Y J будемо називати еквівалентними, якщо (X I Y I) = (X J Y J).

Ранжуємо отримані залежності за наступним правилом rang (X I Y I) > rang (X J Y J), якщо (X I Y I) (X J Y J).

Всім залежностям із одного класу еквівалентності призначаємо однаковий ранг. Незрівнянним залежностям ранги призначаємо довільно.

Крок 7. Діаграма ранжованих залежностей (2 НФ):

У кожному класі еквівалентних залежностей залишаємо по одному представнику. З таблиці видно, що у разі еквівалентних залежностей немає.

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

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

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

Крок 8. Отримуємо сукупність декомпозиційних підсхем

Після проходження алгоритму було отримано 6 таблиць із відповідними первинними ключами:

R1 = oNo, oAddress, oType, oStoreys, oState, oCost, eNoз ключем oNo

R2 = eNo, eName, ePost, eState, eSalary з ключем eNo

R3 = oNo, mNo, count з ключем (oNo, mNo)

R4 = mNo, mName, mCostз ключемmNo

R5 = iNo, iName, iPhone з ключем iNo

R6 = iNo, oNo, sum з ключем (iNo, oNo)

Rational Rose Data Modeler засіб проектування БД

Автори Data Modeler передусім орієнтувалися створення інструменту проектування фізичної моделі даних. При цьому не відбулося відмови від UML як від засобу моделювання даних, а деяким чином було зміщено акценти: тепер UML передбачається використовувати для побудови логічної моделі. По суті, логічна модель - це та сама об'єктна модель, що складається з об'єктів - сутностей. Перехід від логічної моделі до фізичної та навпаки в частині моделювання даних забезпечується Rational Rose автоматично. Для цього введено відповідність елементів моделей.

Таблиця 2.1 Відповідність елементів логічної та фізичної моделі

Логічна модель	Фізична модель
Class (Клас)	Table (Таблиця)
Operation (Операція)	Constraint (Обмеження)
Attribute (Атрибут)	Column (Колонка)
Package (Пакет)	Scheme (Схема)
Component (Компонент)	Database (База даних)
Association (Асоціація)	Relationship (Зв'язок)
	Trigger (Трігер)
	Index (Індекс)

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

Перелік основних можливостей Data Modeler включає:

1. Data Modeler підтримує більшість можливостей структурних CASE-засобів щодо фізичного моделювання даних;

2. Data Modeler забезпечує генерацію ефективної фізичної структури БД, що підтримує механізми забезпечення цілісності посилання;

3. Data Modeler тісно інтегрований з Rational Rose, а діаграма Data Model природним чином вписується в загальну технологію розробки програмного забезпечення з використанням лінійки продуктів фірми Rational Software Corporation;

4. Можна відмовитись від інтеграції Rational Rose з іншими засобами генерації фізичних моделей.

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

Створення логічної моделі

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

Робота Data Modeler заснована на відомому механізмі відображення об'єктної моделі реляційну. Результатом є побудова діаграми "сутність - зв'язок" та подальша генерація опису бази даних на SQL.

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

Подібні документи

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

дипломна робота , доданий 09.03.2010


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

дипломна робота , доданий 05.06.2011


Логічне проектування бази даних автоматизації діяльності будівельної компанії. Класифікація зв'язків. Реляційна модель бази даних Функціональні залежності між атрибутами. Вибір ключів. Нормалізація відносин. Запити до бази даних.

курсова робота , доданий 26.05.2015


Проектування функціональної структури підсистеми "Склад". Даталогічне проектування інформаційної бази даних та опис застосовуваних засобів захисту інформації. Особливості роботи з NET Framework. Розрахунок економічної ефективності проекту.

дипломна робота , доданий 29.06.2011


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

дипломна робота , доданий 22.03.2017


Створення інформаційної системи для автоматизації діяльності компанії щодо реєстрації доставки вантажів транспортної компанії. Аналіз предметної галузі. Методологія функціонального моделювання IDEF0. Контекстна діаграма. Вартісний аналіз у BPwin.

контрольна робота , доданий 05.02.2014


Концепція бази даних, моделі даних. Класифікація бази даних. Системи керування базами даних. Етапи, підходи до проектування баз даних. Розробка бази даних, яка дозволить автоматизувати ведення документації необхідної для діяльності ДЮСШ.

курсова робота , доданий 04.06.2015


Створення бази даних інформаційної системи для обліку продажів побутової техніки та автоматизації документообігу в phpMyAdmin. Функціональна діаграма IDEF0. Створення нового користувача, таблиць, записів у таблиці. Організація сайту на локальному сервері

курсова робота , доданий 11.05.2014


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

курсова робота , доданий 07.02.2016


Аналіз існуючих розробок та вибір стратегії автоматизації діловодства в взаємовідносинах постачальників лікарських препаратів з аптекою. Розробка проекту бази даних аптеки "Рігла". Обґрунтування економічної ефективності розроблення бази даних.

Вступ 3

1. Автоматизація будівельних компаній 5

1.1.

Необхідність автоматизації 5

12

12

Мінуси комплексної автоматизації 12

Плюси комплексної автоматизації 12

Мінуси комплексної автоматизації 13

Плюси комплексної автоматизації 13

1.3.

Рішення в галузі автоматизації 13

2. Короткий аналіз діяльності підприємства 23

3. Пропозиції з автоматизації процесу управління будівельною компанією 30

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

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

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

У будівельних компаніях широко застосовується інженерна системотехніка будівництва, а саме: автоматизовані системи управління будівництвом (АСУС), системи автоматизованого проектування (САПР), автоматизовані системи обробки даних та документації (АСОД) та інші, що сприяють підвищенню ефективності та якості управління.

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

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

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

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

1. Автоматизація будівельних компаній

1.1. Необхідність автоматизації

Необхідність автоматизації управління будівництвом було зрозуміло ще період використання великих ЕОМ, у роки. У СРСР ця проблема мала особливу актуальність через високу централізацію системи управління і великої кількості великих будівництв. Проблема вирішувалася шляхом формування спеціальної служби – автоматизованої системи управління будівництвом (АСУС). Сутність використання АСУС полягала у тому, що всіх рівнях управління між управляючим і керованим ланками з'являлося нове ланка - обчислювальний центр (ВЦ). Обчислювальні центри являли собою великі організації, оснащені великими ЕОМ (другого покоління - на напівпровідниках), з численним персоналом постачальників завдань, програмістів, операторів, кур'єрів зі своїм транспортом, телетайпним зв'язком. Вирішувалися різноманітні завдання, починаючи від "рутинних" (облік витрати та запасів різних ресурсів, нарахування заробітної плати тощо) і закінчуючи складними "оптимізаційними" завданнями, коли вибирався найбільш підходящий варіант організації будь-яких робіт.

На багатьох будівництвах (особливо в Москві) АСУС функціонували досить успішно, але загалом такі системи приживалися погано. В умовах "дефіцитної" економіки одержувані рішення оптимізованих завдань далеко не завжди виявлялися реалістичними, а великий обсяг документації, що роздруковується, зазвичай вивчався будівельниками погано. Керівники будівельного виробництва були готові до настільки сильної перебудові стилю своєї роботи. ВЦ добре використовувалися лише для вирішення завдань обліку – складання відомостей ресурсів, підрахунку заробітної плати тощо.

Швидкий розвиток комп'ютерної техніки в 90-х роках зробив непотрібним громіздкі ВЦ і автоматизація пішла іншим шляхом. Замість великих ЕОМ з'явилися численні персональні комп'ютери, що розмістилися в будівельних організаціях на столах бухгалтерів, інженерів виробничо-технічних відділів, постачальників, комірників, головного інженера і т.д.

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

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

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

Наприкінці 90-х автоматизація більшості будівельних організацій перебувала на описаному 2 етапі, тобто. на стадії використання окремих комп'ютерів та АРМів.

Недоліком автоматизації даного етапу стало недосконалість зв'язку між окремими АРМами і пов'язана з цим необхідність дублювання інформації при її "перекиданні" з одного комп'ютера на інший. З цієї причини подальшим етаном розвитку автоматизованих систем стало створення на базі розрізнених АРМ єдиної інформаційної системи підприємства, що охоплює всі основні сфери era діяльності. Для використання такої системи комп'ютери будівельної організації, інколи ж пов'язаних із нею сторонніх організацій повинні об'єднуватися в єдину комп'ютерну мережу. У цьому програмне забезпечення значно ускладнюється, як і ускладнюється сама апаратна частина, тобто. з'являється безліч додаткових пристроїв, пов'язаних із зберіганням і передачею інформації по різних каналах зв'язку. Виникаючі поточні завдання у сфері діяльності можуть вирішуватися з використанням: даних всієї інформаційної ( " корпоративної " ) системи. Засновані системи управління отримали назву корпоративних інформаційних систем (КІС). Іншими словами КІС - це єдина інформаційна система, що пов'язує, між собою керівництво організації, її структурні підрозділи, іноді і суміжні підприємства, допоміжні служби, що охоплює всі основні сфери діяльності -бухгалтерію, матеріально-технічне забезпечення, загальну технічну політику, поточні організаційні питання та і т.д. Це людино-машинна система, коли він виробнича, господарська і фінансова боку діяльності підприємства стають хіба що цілком " прозорими " , тобто. можна безперервно аналізувати всі результати, тенденції, становище на будівельному ринку, забезпечуючи цим найбільшу ефективність управління. У зарубіжній практиці приблизно такі функції виконують "системи управління ресурсами" ERP.

Як і САПР, такі системи містять безліч стандартних та спеціалізованих модулів, причому кожна конкретна система MOJKIST включатиме, залежно від вимог замовника, свої додаткові модулі та допускати їх подальше розширення. КІСи мають широкі можливості: вони можуть взаємодіяти з програмами САПР, в першу чергу з модулями САМ-і САЕ-систем методи обробки інформації в них включають виконання функцій текстових редакторів, електронних таблиць, баз даних і т.д. Модулі CAD-систем (графічні), характерні для САПРа, в системах управління мають менше значення, по більшу роль набувають модулі управління документообігом (PDM-системи). Для вирішення господарських завдань використовуються економіко-математичні моделі, насамперед різні моделі бізнес-процесів.

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

Управління документообігом

Управління персоналом

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

Фінансове планування

Управління виробничими планами, зокрема календарно-мережевое планування

Аналіз господарську діяльність організації та т. буд.

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

Облік руху матеріалів

Розрахунки із зарплати

Облік основних засобів

Бухгалтерські звіти тощо.

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

Ці модулі розміщуються на комп'ютерах функціональних, лінійних підрозділах, у керівництва, утворюючи автоматизовані робочі місця (АРМи).

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

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

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

1.2. Комплексна автоматизація будівельних компаній

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

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

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

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

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

Рисунок 1 – Інформаційні потоки у будівельній компанії

Кожен відділ і підрозділи мають свій пакет інформації, який він створює в результаті своєї діяльності. Цю інформацію та документацію можуть використовувати у своїй роботі та інші відділи. Але, на жаль, практика показує, що у підприємствах використовується розрізнена система обміну інформацією. Наприклад, бухгалтерія працює в «1С:Бухгалтерії», кошторисний відділ працює у спеціальній програмі для складання кошторисів, підрозділи, які не мають спеціалізованих програмних засобів, працюють у стандартних офісних програмах. У зв'язку з цим неможлива інтеграція даних різних відділів, кожен користується «власним» джерелом однієї й тієї інформації, що призводить до невідповідності даних.

Комплексна автоматизація покликана об'єднати в єдиній базі всі інформаційні потоки, документації та користувачів різних підрозділів.

Малюнок 2 – Автоматизація будівельної компанії

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

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

Таблиця 1 – Переваги та недоліки комплексної автоматизації

Мінуси комплексної автоматизації	Плюси комплексної автоматизації
1. Крім купівлі програмного продукту, необхідні витрати на його використання та подальше супроводження.	1. Один програмний продукт зручніше обслуговувати та супроводжувати, ніж кілька систем різних виробників.
2. Необхідно перед початком робіт упорядкувати існуючий масив інформації: нормативну базу, системи складського, управлінського, бухгалтерського обліку	2. Зручніше використовувати інформаційні ресурси однієї бази підприємства, ніж здійснювати завантаження-вивантаження даних із різних продуктів, що іноді є фактором помилок чи взагалі неможливо.
3. Впровадження системи та навчання фахівців передбачає виділення для цього робочого часу.	3. Тимчасові витрати на пошук інформації та формування документів, звітів тощо. значно скорочуються.

Продовження таблиці 1

Мінуси комплексної автоматизації	Плюси комплексної автоматизації
4. Комплексна автоматизація вимагає активної участі та зацікавленості як керівника, так і співробітників – майбутніх користувачів системи.	4. Збільшується обсяг аналітичної інформації, що допомагає у роботі фінансового, виробничого відділів.
	5. Збільшується обсяг достовірної інформації.
	6. Документообіг, грошовий обіг та всі господарські операції стають прозорими.
	7. Поліпшується самоорганізація персоналу, що з необхідністю планування, контролю тощо.
	8. Прогнозування діяльності підприємства стає достовірнішим.
	9. Зникає проблема несанкціонованих складів та неврахованих матеріалів.
5 . Необхідна наявність відповідного комп'ютерного парку.	10. Більшість паперового документообігу замінюється електронним.

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

1.3. Рішення у сфері автоматизації

1. 1С: Підприємство 8. Управління Будівельною Організацією та 1С:Будівництво

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

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

Продукт розроблений на базі комплексного рішення «1С:Управління виробничим підприємством 8» і включає наступні основні функціональні можливості (з урахуванням функціональних можливостей базового продукту):

Фінансове планування – бюджети, потоки коштів, кредитні та касові плани, фінансові результати.

Фінансовий аналіз - розрахунок фінансових показників, динаміка стосовно інших періодів.

Бухгалтерський та податковий облік – облік фінансової діяльності організації, обов'язкова звітність.

Кошторисна ціноутворення - розрахунок вартості будівництва, складання всіх видів кошторисів, облік виконання, робота з нормативними збірниками.

Управління персоналом - робота з здобувачами, БД персоналу, система кваліфікації, посадові інструкції, системи ВІД, розрахунок ЗП та ЄСП.

Виробниче планування – календарні плани виконання робіт, планування ресурсів (робітники, матеріали, механізми, транспорт).

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

Аналіз виробничих показників - розрахунок показників виконання, динаміка стосовно інших періодів.

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

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

Найбільший ефект використання зміни «1С:Управління будівельною організацією» дає у будівельних організаціях із чисельністю від 100 зайнятих і зажадав від 10 робочих місць, там де потрібна організація єдиного інформаційного простору кількох відділів і підрозділів. Особливо актуальною є конфігурація для розподілених структур у формі групи компаній або організацій з філіями.

Конфігурація «1С:Управління будівельною організацією» надає:

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

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

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

1С: Будівництво

Використання програм 1С для будівництва дозволяє успішно реалізовувати проекти з комплексної автоматизації всіх гравців інвестиційно-будівельного ринку:

1. Девелоперів;

2. Замовників будівництва;

3. Проектні організації;

4. Генпідрядні організації;

5. Підрядні організації;

7. Управління механізації та автотранспорту;

8. Виробників будівельних матеріалів;

9. Експлуатують компанії.

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

2. Менеджер будівництва 2.0

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

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

Основні засади роботи системи

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

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

Звітність Менеджера будівництва 2.0 дозволяє отримувати всю необхідну інформацію у розрізі об'єктів/робіт/статей витрат у всіх підсистемах;

Конфіденційність фінансової інформації. У конфігурації реалізовано розмежування доступу користувачів до рахунків управлінського плану рахунків, статей витрат і до пов'язаної з ними інформації;

Ведення управлінського обліку окремо від бухгалтерського. Дані управлінського обліку зберігаються окремо від даних бухгалтерії.

Переваги

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

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

Комфортна робота щодня

Менеджер будівництва 2.0 має продуманий інтерфейс користувача, зі зручними, інтуїтивно зрозумілими меню;

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

Економія часу за рахунок автоматизованого формування документів

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

Одночасне формування двох версій документів, довідників та звітів: для виробництва та для замовника

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

Простий та швидкий перехід до автоматизованого обліку

Щоб перейти до обліку в Менеджері будівництва 2.0, потрібно мінімальний час. Зазвичай на початкове освоєння системи потрібно трохи більше тижня;

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

Максимальна гнучкість та настроюваність

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

Робота з розподіленими інформаційними базами

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

Рисунок 3 – Фрагмент програмного продукту Менеджер будівництва

3. Респект: Облік договорів (для будівельних компаній)

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

Можливості підсистеми.

У програмному продукті «Облік договорів» передбачено таку функціональність:

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

Введення та зберігання тексту договору, його додатків, додаткових угод та їх різних редакцій;

Введення та зберігання інформації про структуру договору, його суб'єктів та предмет договору, про зобов'язання за договором та їх погашення;

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

Введення, зберігання та аналіз розрахунково-грошових, товарно-грошових та товарно-розпорядчих документів за договором;

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

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

Введення умов та проведення розрахунку економічних санкцій за договорами;

Угруповання договорів за різними ознаками (груп, категорій, центрів витрат тощо);

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

Збір та зберігання інформації про потреби підрозділів підприємства, об'єднання отриманих заявок та моніторинг їх виконання;

Поділ доступу до інформації з договорів серед відповідальних виконавців;

Проведення аналізу цін з урахуванням раніше укладених договорів.

Технологічні особливості підсистеми

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

Погодження та підписання договорів

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

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

Після того, як договір підписано, на перший план виходять завдання управлінського (контроль зобов'язань, термінів виконання та ін.) та бухгалтерського обліку. Для обох завдань ключовим є поняття «зобов'язання». Цивільний кодекс РФ констатує, що договір є завжди набір зустрічних зобов'язань кількох сторін. У цьому зобов'язання може бути як «товарні» (постачання будь-яких товарів чи надання послуг у визначені терміни і певних умов), і «грошові» (здійснення оплати). Додаток «Облік договорів» підтримує всі можливі схеми зобов'язань – бартер, взаємні заліки, передача зобов'язань третім особам тощо. Зобов'язання містить інформацію про те, до якого з учасників договору воно належить, а також про суму, дату початку дії зобов'язання. З зобов'язань формуються плановані платежі за договором - платіжний календар, визначальний, хто з учасників договору, коли, кому, скільки у якій валюті має платити. Запланований платіж може здійснюватися за договором в цілому, за його етапом, списком етапів, частиною етапу або більш складною схемою (припустимо, 50% - за фактом закриття робіт на одному етапі і тим же платежем 50% - передоплата за наступним етапом). Вся ця інформація дозволяє не просто відстежувати кредиторську та дебіторську заборгованість за контрагентами, а й отримувати необхідну аналітику за зобов'язаннями - за датами, договорами, етапами договору, товарними позиціями та іншими параметрами. Крім того, коли в організації призначено співробітника, відповідального за приймання та контроль робіт по етапах, застосовану в системі схему документообігу дуже зручно використовувати не тільки при укладанні договору, але і для контролю його виконання. Для цього він у маршруті договору чи етапу вводяться елементи, які стосуються процесу виконання. Керівництво може будь-якої миті отримати відомості про те, які договори або етапи закріплені за певним співробітником, які з них прострочені (тобто роботи не були закриті вчасно) та іншу управлінську інформацію. Програмний продукт "Респект: Облік договорів" дозволяє вести облік документів, що підтверджують виконання встановлених у договорі зобов'язань. Існують два види таких документів – «товарні» (Прибуткові накладні, Акти виконаних робіт) та «платіжні». Ці документи можна вводити незалежно один від одного, що особливо зручно в тому випадку, коли із системою працює багато людей, а співробітники, які закривають Акти виконаних робіт або здійснюють оплату, до самих договорів доступу не мають. Пізніше система «прив'язує» ці платежі чи акти до відповідних договорів. З платіжних документів виконуються платіжні зобов'язання, з'являється чи коригується кредиторсько-дебіторська заборгованість, формуються проведення за рахунками. Товарні документи "закривають" товарні зобов'язання.

Зручність інтерфейсу користувача

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

2. Короткий аналіз діяльності підприємства

Будівельна фірма ТОВ «Техтрон» є підприємством малого бізнесу м. Кірова. Організаційно-правова форма – відкрите акціонерне товариство. Організовано з одержання прибутку. Основний вид діяльності – будівництво, ремонт та обслуговування об'єктів різного соціально-господарського призначення.

Будівельна фірма ТОВ «Техтрон» надає такі послуги:

Будівництво об'єктів 1 та 2 категорії складності.

Оздоблювальні роботи фасадів та внутрішніх приміщень.

Земляні роботи.

Фундаментні роботи

Прокладання зовнішніх інженерних мереж, каналізації та водопроводу.

Покрівельні роботи.

Монтаж металоконструкцій.

Електротехнічні роботи до 1000 кВт.

Будівництво, ремонт та утримання автомобільних доріг.

Оптова торгівля матеріалами, що стосуються будівельної промисловості.

Автоперевезення у межах Російської Федерації.

Надання ремонтно-будівельних послуг населенню.

Послуги генерального підрядника.

До структури підприємства входять такі підрозділи рис.4.

Малюнок 4 – Структурна схема ТОВ «Техтрон»

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

Бухгалтерія.

Кошторисно-договірний відділ (який насправді входить до складу відділу постачання, оскільки функції виконує одна людина).

Головний інженер.

Планово-економічний відділ.

Відділ постачання.

Начальники дільниць.

Юрист-консул.

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

Бухгалтерія.

Кошторисно-договірний відділ.

Планово-економічний відділ.

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

Рисунок 5 - Схема реалізації завдань з обліку договорів

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

Завдання постачальника включає всі аспекти роботи установи з господарськими договорами. Після підписання договору завдань бухгалтерського обліку ключовим стає поняття «зобов'язання», які можуть бути «товарними» чи «грошовими». Завдання постачання підтримує всі можливі схеми зобов'язань – бартер, взаємні заліки, передача зобов'язань третім особам тощо. З зобов'язань формуються плановані платежі за договором. З платіжних документів виконуються платіжні зобов'язання, з'являється чи коригується кредитно-дебіторська заборгованість, формуються проведення за рахунками, товарні документи «закривають» товарні зобов'язання. Набір розв'язання бухгалтерських завдань дозволяє економісту – постачальнику отримувати інформацію, що аналізується та дозволяє керівництву приймати правильні управлінські рішення, що призводить до рентабельної роботи підприємства. Тому інформаційна система, що розробляється, для АРМ є економічною інформаційною системою.

Обґрунтування необхідності та мети використання обчислювальної техніки для вирішення задачі

У будівельній фірмі ТОВ "Техтрон" традиційно використовується програмне забезпечення Microsoft Office і має такі характеристики:

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

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

відсутні програмні механізми розмежування доступу до інформації;

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

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

Усі перелічені недоліки дозволяють зробити висновок необхідність автоматизації праці економіста - постачальника.

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

підготовчий етап;

етап оформлення договорів;

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

етап урахування договорів;

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

етап створення звітності

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

Таблиця 2 – Інформаційні процеси етапів

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

Продовження таблиці 2

Необхідність більш комплексної автоматизації у будівельній компанії – це виконання таких функцій:

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

Забезпечення автоматизованого введення інформації за допомогою екранних форм.

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

• формування довідкової інформації,

  ведення обліку договорів,

  облік проектно-кошторисної документації,

  облік виконання договірних зобов'язань,

Реалізація автоматизованого способу отримання оперативної та планової звітності.

Організація системи аналізу даних.

Організація автоматизованої системи звітності.

У існуючому процесі є ряд недоліків:

При автоматизації процесу ці недоліки можна усунути за допомогою:

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

автоматичної реєстрації нових документів;

Можливості створення потрібних запитів до інформаційної системи;

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

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

Організація обліку договорів на основі "Респект: облік договорів" зможе вирішити поставлені завдання.

3. Пропозиції з автоматизації процесу управління будівельною компанією

Для усунення недоліків пропонується використання програмного продукту «Респект: облік договорів». Використання програмного продукту «Респект: облік договорів» забезпечує:

Систематизацію обліку та зберігання документів;

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

Ефективне управління процесами руху та обробки документів;

Скорочення часу процедур узгодження договорів та прийняття рішень;

Скорочення мимовільних витрат робочого дня працівників;

Мінімізацію фінансових витрат за облік договорів.

«Респект: облік договорів»- Універсальний програмний продукт для організації системи договірної роботи на підприємстві. Програма автоматизує облік договорів і дозволяє інтегрувати ведення договорів у планово-фінансовий контур підприємства.

Основні можливості програми:

Підготовкадоговорів:

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

Узгодження договорів:

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

Формування бланків документів:

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

Ведення журналу договорів підприємства:

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

Планування:

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

Формування універсальних звітів

Контроль за виконанням договорів:

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

Аналіз результатів договірної роботи:

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

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

Усередині картки договору у вигляді файлів можуть бути збережені, наприклад:

Відскановані оригінали договорів;

Схеми та специфікації;

табличні документи;

Документи довільного тримання.

Інтеграція в 1С:Бухгалтерію 8

Інтеграція в 1С: Управління торгівлею 8

Інтеграція в 1С:УПП 8

Зберігання договорів

Висновок

У цій роботі був розглянутий варіант пропозиції автоматизації будівельної компанії на базі впровадження програмного продукту «Респект: Облік договорів», який дозволить більш оптимального та ефективно організувати роботу даного підприємства, усуне виявлені недоліки:

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

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

Важко відстежувати рух документа всіх етапах його життєвого циклу;

Трудомісткість отримання зведених звітів;

Тривалість термінів підготовки та погодження документів;

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

бібліографічний список

Маклаков С.В. BPWin та ERWin.

CASE засоби розробки інформаційних систем. -М.: 1999р. -297с.

Маклаков С.В. Моделювання бізнес-процесів із BPwin 4.0. - М: 2002р.