РЕФЕРАТ
На тему: «Впровадження автоматизованих інформаційних систем у сфері житлово-комунального господарства»
1. Огляд учасників і їх частки діяльності в ЖКГ
Підхід до огляду
Спочатку ідея структури огляду намічалася в якості порівняльної характеристики рішень. Складалася вона в наборі різних програм, складанні критеріїв порівняння та визначенні порівняльної оцінки рішень в таблиці, де були б проставлені «галочки» «є / немає». Проте після отримання першої порції інформації стало ясно, що такий підхід не годиться: з причини величезної кількості програм, які заслуговують на увагу. Порівняльна табличка вийшла б нечитабельних розмірів.
Вирішено було змінити ідею огляду, і побудувати його у вигляді опису «узагальненої системи для автоматизації ЖКГ», яке містить всі функціональні можливості, методи рішення, архітектуру «ідеальної системи». Така інформація може істотно допомогти відповідальним фахівцям у виборі конкретного програмного рішення, зорієнтуватися в предметній області та оцінити повноту функціональних можливостей наданих різними системами автоматизації.
Що таке «ЖКГ»?
Щоб виключити непорозуміння при аналізі інформаційних систем для ЖКГ, ми повинні конкретизувати визначення терміна ЖКГ, який буде використовуватися у цьому огляді.
Перш за все, визначимося з предметною областю: що ж відноситься до ЖКГ? Розшифровка «Житлово-комунальний комплекс» недостатньо конкретна.
Так, наприклад, чи можна віднести до ЖКГ системи, що використовуються муніципальними органами для керування комунальними підприємствами? Внедренец або програміст, що займається інформаційною системою для міської влади (може бути «для автоматизації обліку в міському господарстві») відповість на це питання ствердно. Він вважає, що у нього є підсистеми «бухгалтерія», «кадри», «промисловість» ...., І серед інших інших є «ЖКГ», яка веде облік житлових будинків, черг на отримання квартири тощо А аналітик-програміст банку, який займається супроводом «операційного дня», може заявити про те, що у нього є блок «ЖКГ», призначений для імпорту банківських проводок із системи платежів населення.
Щоб визначитися з терміном, звернемося до структури прикладної області. У центрі завдання перебуває робота з населенням по всіх послугах, пов'язаних з житлом. Всі підприємства, організації, служби, які працюють безпосередньо з населенням, входять до першого рівня розглянутої задачі. Це рівень наших інтересів у цьому огляді.
Наступний рівень - це установи, які працюють не з населенням, а з підприємствами першого рівня. Інформаційні системи цих установ можуть містити модулі, призначені для роботи з підприємствами першого рівня. І так, як для них ця робота проводиться в напрямку ЖКГ, то вони можуть також використовувати цю абревіатуру для назви своїх модулів і функціональності систем. Ми не будемо в цьому огляді розглядати цей рівень - поки обмежимося першим рівнем - робота з населенням.
Зрозуміло, на підприємствах ЖКГ використовуються інформаційні системи не тільки для роботи з населенням. Бухгалтерський, управлінський, податковий облік їм так само властиві, як і всім іншим підприємствам. Але ці завдання практично ні чим не відрізняються від аналогічних завдань на інших типах підприємств. Не будемо їм приділяти увагу в цьому огляді.
Таким чином, під ЖКГ у цьому матеріалі увазі всі підприємства, установи, служби і т.п., які працюють з населенням безпосередньо за всіма видами послуг, пов'язаних з житлом. А з усього безлічі інформаційних систем, що використовуються для ЖКГ, розглянемо ті, які призначені для роботи з населенням.
Інтереси учасників ЖКГ
Населення
У центрі уваги житлово-комунального комплексу знаходиться населення. Для його обслуговування і призначені підприємства ЖКГ.
Перелік послуг та їх вартість для населення визначається місцевою владою. Також населення не може вплинути на величину наданих пільг і субсидій. Люди отримують тільки те, що їм належить, не більше. Менше можна, якщо не зможуть оформити необхідні документи у встановлені законом терміни.
Від населення обов'язково потрібні дві речі: оплата за отримані послуги та надання довідок, пов'язаних з комунальними платежами, в різні інстанції. Також за ініціативи мешканців можливі турботи, пов'язані з розглядом по сумах виставлених рахунків, отриманих пільг, субсидій. Якщо з кількістю грошей, необхідних для оплати послуг, людей мириться і це не є для них дратівливим чинником, то для ходіння по пунктах прийому платежів, по інстанціях за довідками, простоювання у чергах за необхідними документами (щоб спочатку їх отримати, і потім здати) , не тільки потрібен час, але і витрати нервів.
Тому тим головним подарунком, який може отримати населення від використання інформаційних систем у сфері ЖКГ, є економія часу і зниження негативних емоцій, пов'язаних із спілкуванням з установами ЖКГ.
Постачальники послуг
Це категорія підприємств і організацій, які надають для населення різні послуги. Прикладами таких підприємств є:
- Служби водоканалів, тепломереж, електро-та газопостачальні підприємства,
- Житлово-експлуатаційні підприємства (ЖЕКи),
- Товариства і кооперативи житла, садових ділянок, гаражів і т.п.
- Телефонний зв'язок,
- Служби технічної інвентаризації.
Існує також група бюджетних установ, які не є постачальниками побутових послуг, але з якими населення пов'язано фінансовими відносинами. Цією установою населення платить внески, податки, штрафи і т.п. До них, наприклад, відносяться: ДАІ і виконавча служба.
Особливість послуг, що надаються такими підприємствами така, що вартість і обсяг послуг практично не залежать від самого підприємства, так як вони регламентуються місцевими властями. Крім того, у сфері ЖКГ існує природна монополія з надання послуг - у мешканців міста практично немає можливості вибору постачальника послуг, а у постачальників послуг, у свою чергу, відсутня необхідність боротьби з конкурентами за клієнтів: досить того, щоб якість і обсяг послуг були не нижче нормативних. Як не дивно, але в даний час постачальникам навіть не потрібно прагнути до зниження собівартості послуг, що надаються. Це випливає з методики формування тарифів: вони розраховуються на основі планових витрат підприємств, і якщо фактичні витрати виявляться менше, то різниця поточного року повинна перераховуватися до бюджету, а тарифи на наступний рік будуть знижені у зв'язку зі зниженням фактичних витрат.
Єдине, що цікавить постачальників у відносинах з населенням - це швидше і надійніше отримати оплату за надані послуги. Цього можна досягти або примусовим методом, або наданням максимальної зручності для мешканців при виконанні взаєморозрахунків. Примусові методи доступні дуже не багатьом постачальникам. Це електрики, телефоністи, а також ті, хто оплату за послуги бере наперед. Для інших постачальників залишається тільки другий шлях. Він полягає в тому, що б мінімізувати витрати часу і виключити негативні емоції у населення при виконанні взаєморозрахунків, з одного боку, та надати інформації про стан взаєморозрахунків для служби збуту і юристів постачальника - з іншого. Перша частина виключає рішення платника «відкласти оплату на потім», а друга - надає дані для нагадувань і для підготовки цивілізованих вимог, тобто підготовки позовних вимог для суду.
Однак повернемося до нашої теми. Інформаційні системи для постачальників послуг повинні вирішувати задачі, що перебувають у сфері їх життєвих інтересів. Якщо виключити звичайні завдання, які вирішуються на всіх інших підприємствах, залишаються взаємини з населенням. Інформаційна система, з одного боку, повинна забезпечити службу збуту і юристів відомостями, необхідними для спілкування з населенням, а з іншого боку - надати людям максимальні зручності для надання відомостей про отримані послуги та виконання платежів за них.
Банки
Під терміном «Банки» тут маємо на увазі всі установи, які виконують прийом платежів від населення. Пошта, ощадкаса також відносяться сюди. Для деяких непопулярних банків прийом платежів від населення - це просто навантаження, яку вони повинні виконувати за умовами ліцензії банків. Але для інших, наприклад, для пошти, цей вид діяльності є одним з найбільш рентабельних. Тому, для них природним є прагнення привернути до себе якомога більше клієнтів, пропустити через себе якомога більше грошей. Приплив клієнтів для виконання платежів безпосередньо залежить від зручностей виконання платежів у пунктах прийому цього банку. Народ не піде туди, де доводиться стояти в черзі. Люди будуть платити там, де, крім прийому грошей їм покажуть, скільки, кому, і за що вони повинні, візьмуть показання приладів обліку, нададуть «лист» від постачальника послуг.
Тому в сфері надання зручностей населенню при виконанні платежів інтереси банків збігаються з інтересами постачальників послуг. Це є істотним аргументом до того, щоб у банків і в постачальників послуг використовувалося програмне забезпечення, що забезпечує зручне проходження платежів по ланцюгу «клієнт - банк - постачальник послуг».
ЖЕКи
У системі ЖКГ ЖЕКи виступають з двох сторін: як постачальники послуг і як установи прийому запитів населення. В якості постачальників послуг у галузі використання інформаційних систем їм властиво все, що і для інших постачальників. Розглянемо їх саме як установи по прийому запитів населення.
Як установа по роботі з населенням, ЖЕК має найсвіжішою інформацією про склад мешканців. Ці дані потрібні практично всім постачальникам послуг, вартість та обсяг яких залежить від кількості проживаючих. І вони готові за неї платити. Навіть організація постачальниками послуг власного прийому населення з метою отримання свіжої інформації не забезпечує своєчасність її надходження, особливо, коли ця інформація призводить до збільшення вартості отримуваних послуг.
Розрахунково-касовий центр
Це фірма, яка береться за організацію інформаційних потоків між всіма учасниками ЖКГ і бере за цю роботу відсоток від сплачених грошей.
Теоретично, без РКЦ можна й обійтися. Але на практиці настроювання взаємозв'язків між учасниками, узгодження інформації, підстрахування тих постачальників, у яких не встановлено автоматизовані системи, без РКЦ не обходиться. Ця фірма є посередником між банками і постачальниками послуг в передачі інформації як в одну, так і в інший бік. Вона підтримує загальну базу даних абонентів.
Іноді ця фірма бере на себе зв'язку з бюджетними установами (пільги, субсидії). Але, на наш погляд, цим повинні займатися самі постачальники послуг, тому що це відповідальна робота і, при виявленні будь-яких порушень, штрафи накладаються не на РКЦ а на постачальника послуг.
РКЦ зазвичай є окремим самостійним підприємством. Але так, як організувати роботу в масштабах міста без підтримки місцевої влади практично неможливо, і так як це місце насичене конфіденційною інформацією, то зазвичай така фірма курується представниками місцевою владою.
Для прийняття розрахунків у населення в автоматичному режимі є система. Вона функціонує в межах розрахункових чи розрахунково-касових центрів різної приналежності, які не залежать від географічного розташування, і можуть бути, як міського, обласного, так і регіонального масштабу. Організація роботи такого підприємства будується на підставі цілей її учасників. Це можуть бути власники самого центру, муніципальна влада, ті, хто інвестував проект і інш. Оскільки переоцінити значення розрахункового центру важко, тому для його нормальної роботи необхідно скрупульозно підходити до вибору надійного технологічного рішення, попередньо зваживши всі «за» і «проти».
Установи влади
Враховуючи монопольний характер послуг, що надаються підприємствами ЖКГ, на захисті інтересів населення може стояти лише місцева влада. Відстеження цін, кількості і якості послуг, що поставляються, проблем у взаєминах населення і постачальників послуг - це святий обов'язок муніципальної влади та її улюблена робота.
Для виконання такої роботи у виконавчій владі повинна бути достатня інформація. При цьому інформація повинна надходити не від постачальників послуг (вже відфільтрована), а безпосередньо з системи ЖКГ. Забезпечити такий інформацією органи влади може тільки серйозна інформаційна система, що працює в ЖКГ як в єдиному комплексі.
Що дає автоматизація ЖКГ постачальникам послуг?
Безперечну вигоду. Перш за все, це підвищення рівня оплати для постачальників послуг. Зменшується основна заборгованість населення, яка є основним бичем для постачальників послуг. Витрати на інформаційну систему, що виражаються в тисячах, зменшують заборгованість на мільйони (ніяким збільшенням штату служби збуту і контролю таких результатів не досягти). Не затребувані борги через деякі час безповоротно зникають із-за неможливості їх запитання щодо термінів позовної давності.
Позитивним прикладом може служити Новосибірськ, де єдина автоматизована система прийому комунальних платежів виправдала себе в тому плані, що з впровадженням АС «Місто» (www.radey.ru) платежі від населення підвищилися на 43%.
Другий фактор складно виразити в грошах - це зручності для населення при виконанні платежів. Цей фактор покращує загальну соціальну обстановку в місті, покращує ставлення населення до виконавчої влади, впливає на її підтримку.
Третій фактор - підвищення ефективності використання бюджетних коштів, призначених для пільгування та субсидування населення у сфері комунальних платежів. МЕРТ РФ розглядає можливість часткового використання єдиної автоматизованої системи платежів в Москві, відзначаючи, що це призведе до економії тридцяти мільйонів доларів на рік, оскільки переплата соціальних виплат мінімізується.
І, на кінець, четвертий фактор той, про який ми ніколи не забуваємо, коли збираємося впроваджувати інформаційну систему - автоматизація праці задіяних служб підприємств, учасників ЖКГ. Це не тільки персоніфікує облік пільговиків і збільшить продуктивність праці інспекторів, а й надасть можливість отримання оперативної, повноцінної і достовірної звітної інформації.
2. Огляд рішень автоматизації в ЖКГ: програмне забезпечення ЖКГ
У попередній частині були розглянуті склад учасників і їх інтереси в загальноміської системи. Тепер пропонуємо до розгляду функціональні можливості, якими володіють автоматизовані системи, що використовуються в житлово-комунальному господарстві (ЖКГ) і які призначені для задоволення інтересів учасників.
Для цього підемо шляхом об'єднання: з усіх зустрілися автоматизованих систем виберемо ті можливості, які в них використовуються, при цьому, не повторюючись для одних і тих самих функцій. Таким чином, вийде об'єднаний функціонал деякої абстрактної системи, яка може все, що є на сьогоднішній день. Точніше все, що представлено в системах, використовуваних для огляду. Сподіваюся, що такий перелік функціональних можливостей автоматизованих систем ЖКГ буде корисний і для Замовників, які бажають впровадити у себе таку систему, і для розробників, які планують її створення. «Не забути» про яку небудь стороні застосування автоматизованої системи на ранній стадії її розробки або при виборі для закупівлі, це дуже важливо як для користувачів, так і для розробників.
Список завдань, що вирішуються автоматизованими системами в ЖКГ, занадто довгий для того, щоб її можна було викласти, не піклуючись про його структуру. Ми об'єднаємо функціонал по групах, кожна з яких призначена для використання на відповідному учаснику ЖКГ
Використовуємо склад учасників, перерахований в першій частині:
- Населення
- Постачальники послуг
- Банки, пункти прийому платежів
- ЖЕКи
- Розрахунково-касовий центр
- Установи влади
Населення
Населення - це основний учасник ЖКГ, навколо і заради якого все побудовано, і єдиний учасник, для якого спеціального програмного забезпечення не використовується. Можливість оплати за допомогою комп'ютерного зв'язку в країнах колишнього Радянського Союзу залишається поки теоретичної. Хоча і не скрізь. Наприклад, в Казахстані можна сплатити комунальні послуги практично з будь-якого банкомату. У деяких банків навіть є спеціальні банкомати, які спеціалізовані виключно під оплату компослуг. Так само в банківській системі Казахстану існує така послуга, як Інтернет-рахунок. Приходиш у банк, відкриваєш такий рахунок, поповнюєш його потрібною сумою і можеш цілий рік оплачувати користування світлом, газом, водою і т.д. з домашнього комп'ютера. Але, як бачимо, навіть за наявності такої можливості, то програмне забезпечення, яке призначене для виконання таких платежів, належить або до банківських систем, або до систем розрахунково-касового центру.
Постачальники послуг
У свою чергу, функціонал IT-систем постачальника послуг розділимо на групи, відповідні зазвичай ділянках роботи виконавців:
- Розрахунок відпустки
- Робота з приладами обліку
- Перерахунки
- Облік пільг
- Облік субсидій
- Оплата за послуги
- Облік обертів
- Розрахунок пені
- Юридична служба
- Звіти
Розрахунок відпустки послуг
Не дивлячись на велику різноманітність постачальників послуг населенню, завдання, що стоять перед їх автоматизованими системами, одні й ті ж, за деяким винятком. І, мабуть, єдина відмінність полягає в засобах доставки послуг. Але трудомісткість автоматизації обліку різних видів послуг суттєво відрізняється. Вона знаходиться в діапазоні від елементарної формули до складних розрахункових алгоритмів.
В основі розрахунку відпустки кожної послуги лежить елементарна формула: вартість = кількість x на ціну. Звичайним розрахунковим періодом є календарний місяць. Як правило, розцінки встановлюються місцевою владою Кількість або визначається за приладами, або є розрахунковою величиною, яка залежить від різних параметрів. Якщо допустити, що в межах звітного місяця не змінюється ні ціна, ні аргументи кількості, то просто застосовується ця формула. Ряд систем пропонують ввести цю формулу засобами настройки.
Але на практиці такого сталості немає. Просто параметри для розрахунку одних видів послуг змінюються частіше, а для інших - рідше. Наприклад, плата за квартиру залежить від кількості квадратних метрів, що є постійною величиною, а за воду - залежить від кількості проживаючих, в тому числі, тимчасово вибули або знову прописаних. Цей параметр змінюється набагато частіше. Але можливість зміни параметрів саме по собі ще не є проблемою для систем автоматизації. Проблему становить те, що і ціна, так і будь-який з параметрів, від якого залежить кількість наданої послуги, може змінюватися в будь-який час. Зміна його з «1-го числа звітного місяця» - це рідкісний збіг.
На складність визначення кількості наданих послуг розрахунковим шляхом також впливає можливість врахування цих видів послуг за обліковими приладами. Прилади можуть бути встановлені або виведені з експлуатації в будь-який момент часу. За той проміжок, коли прилади не використовуються, система розраховує кількість розрахунковим шляхом, а в період працюючих приладів - за їх показниками.
Наступна трудомістке завдання - це облік тимчасових відключень і якості надаваних послуг. У загальноміської системи ЖКГ є різні точки визначення часу відключення і якість послуг. Наприклад, дані про відключення теплової магістралі означають, що в цей період були відключені всі абоненти, система опалення яких підключена до цієї магістралі прямо або за допомогою різних розгалужень.
Одночасно на підприємство можуть надходити незалежні дані про інші відключеннях, наприклад, про ремонт якої-небудь гілки, що відходить від цієї магістралі, а з ЖЕКу приходить інформація про індивідуальні відключення. Періоди різних документів можуть перетинатися. Аналогічно поступають на підприємство дані про відхилення від нормативної якості надаваних послуг. Для обліку інформації про відключення та якість послуг IT-система має в своїй базі даних модель засобів доставки послуг (зазвичай це деревовидна структура) та засоби для обліку перетинань періодів, в діапазоні яких діють надаються дані.
Вище ми розглянули ті фактори, які впливають на складність розрахункових процедур для визначення кількості наданих послуг. Наступна сторона IT-систем для ЖКГ, яка визначає їх живучість, - це підхід до надання даних про різні види послуг. Виділяються два підходи: з постійним і змінним набором послуг. Терміни «постійний» та «змінний» умовні. Вони просто характеризують обсяг зусиль і рівень небезпеки пошкодження працюючої системи для додавання нової або виключення існуючої послуги. Як приклад реалізації, в першому випадку використовується одна таблиця, в якій для кожного виду послуг відводиться набір полів, і одна процедура, що виконує розрахунок по всіх послугах. Другий варіант реалізації - під кожен вид послуг відводиться своя таблиця і своя процедура розрахунку. У першому випадку при модифікаціях доводиться втручатися у вже діючі частини системи, чому має передувати ретельне вивчення, і що призводить до необхідності тестування не тільки нових доробок, а і раніше використовуваних функцій. У другому випадку просто додається новий набір об'єктів системи, не зачіпаючи функціонуючий.
Робота з приладами обліку
На перший погляд, прилади обліку знімають всі проблеми з розрахунком кількості наданих послуг. Але практиці справа йде зовсім навпаки - вони лише ускладнюють життя програмістів при складанні процедур розрахунку, а інспекторів - за поясненням результатів для абонентів.
Прилади бувають індивідуальні та групові. Індивідуальні прилади знаходяться в абонентів, таких приладів може бути довільна кількість (на кухні, в санвузлі, у дворі тощо). Групові прилади містять свідчення на групу абонентів, наприклад, будинок, під'їзд. Їх показання розподіляються між абонентами за певними критеріями, наприклад, теплова енергія - пропорційно площі, а вода - пропорційно кількості мешканців, точніше людино / днів. При цьому враховується наявність індивідуальних приладів у абонентів, що відносяться до цієї групи. Після розподілу, кількість, що припадає на кожного абонента, використовується в розрахунках точно так само, як і показання індивідуальних приладів.
Список труднощів та інформаційно-технічних проблем при роботі з приладами досить значний.
Перша очевидна трудність - це правильність внесення показань приладів. З'являються такі помилки:
- Ввели свідчення не того приладу;
- Поточний показання явно не відповідає попередньому;
- Помилка в періоді, за який знято показання;
- Явна помилка в кількості, наступного з отриманих свідчень.
Для запобігання цих помилок використовуються засоби діагностики вихідних даних. Без такої діагностики виправлення виливається у сто крат дорожче - прийом абонента, ручний перерахунок, з'ясування відносин («хто винен?").
Друга складність - це несвоєчасність надання даних про показання приладу. І складність полягає не стільки в різних перерахунках для абонента, стільки в коректуваннях інформації, поданої у державні служби обліку пільг і субсидій.
Третя - прилади повинні періодично зніматися на повірку. Цей процес повинен бути поставлений на контроль. Для абонентів, у яких прострочена повірка, розрахунок кількості відпустки виконується розрахунковим методом. Несвоєчасне введення даних про повернення приладів з повірки знову приводить до необхідності перерахунків.
І, нарешті, вже просто проблемою є зняття на ремонт або на перевірку одного приладу з декількох, що використовуються в одного і того ж абонента. Такі розрахунки виконуються тільки вручну. Нагромадження функціоналу системи для таких перерахунків вимагало б введення додаткових параметрів, трудомісткість чого істотно перевищує трудомісткість виконання таких перерахунків «вручну». На практиці такі ситуації виключаються. Вводиться правило, або всі прилади, або жодного.
Перерахунки
Перерахунки - це розрахунок величини коригування кількості і вартості наданих послуг для одного або декількох минулих періодів, або втручання в результат розрахунку поточного періоду. Необхідність у перерахунках обумовлена двома причинами: недостовірними вихідними даними і недостатньо розвиненим функціоналом системи.
Неправильні дані для розрахунків можуть бути надані з вини абонентів, з вини користувачів програми, з причин, незалежних від постачальника послуг. Абонент помиляється в наданні даних про його особовому рахунку, наприклад, показань приладу. Користувач програми помиляється при введенні інформації (переплутав абонента, зробив помилку при введенні дати і т.п.). До об'єктивних причин належить несвоєчасна інформації про вжиті тарифах, відключеннях і т.п.
Не досить розвинений функціонал призводить до неправильних даних. Наприклад, програма допускає протягом одного звітного періоду тільки одна зміна кількості проживаючих людей. Але ймовірно зміна кілька разів, наприклад, з 10-го числа один поїхав, а 20-го один приїхав. У такому випадку в результатах розрахунку буде помилка, яку користувач програми виправляє шляхом введення коригувань для поточного звітного періоду. Незалежно від причин, система повинна мати можливість перерахунків. Чим більш розвинений функціонал, тим більше перерахунків виконуються автоматично. Але процес ручного втручання повинен забезпечуватися в будь-якій системі.
Для забезпечення можливості перерахунків, база даних системи містить історію результатів розрахунку за всі звітні періоди за всіма видами послуг. Всі дані містять два параметри часу: звітний і розрахунковий періоди. Звітний - це період, в якому виконаний розрахунок (коригування). Розрахунковий - період, до якого відносяться розрахункові або вихідні дані.
Облік пільг
Пільга з боку абонента - це та сума, на яку йому зменшується платіж за комунальні послуги. Йому виставляється рахунок на 25%, 50% і т.д. менше, ніж іншим таким же абонентам, але не мають пільги. Пільга з боку постачальника послуг - це сума, яку за абонента платить бюджет. Пільга не зменшує загальну вартість відпущених послуг. Це просто один з видів оплати.
Існує ціла система пільг. За джерела фінансування структуру пільг можна зобразити у вигляді дерева. Зазвичай зведена відомість наданих пільг містить дані по кожному рівню цієї структури. Сума пільг, як правило, задається у вигляді відсотка від суми отриманих послуг. Але в загальному випадку це нелінійна залежність. Нелінійність визначається двома основними факторами: наявністю соціальних норм споживання послуг і залежністю між різними пільгами одного і того ж абонента.
Соціальна норма споживання - це розрахунковий нормативну кількість послуг, розраховане на одну людину. У межах цієї величини здійснюється пільгування. Перевищення кількості послуг у порівнянні з нормативами не льготируется. Наприклад, норма споживання електроенергії на людину становить 75 кВтг. Пільга в абонента - 50%. Отримано у звітному періоді 90 кВтг. З них 75 відпускаються за пів ціни, а решту 15 - по повній.
Залежність між пільгами складається або в самому характері пільги, або в обмеженні загальною вартістю отриманих послуг. Характер пільги відображається в методі розрахунку. Наприклад, пільга виконкому сільським вчителям - 100% від суми, що залишилися після застосування інших пільг. Обмеження вартістю відпустки полягає в тому, що сума пільг за всіма привілеям абонента не повинна перевищувати загальну вартість відпущеної продукції.
При розрахунку пільг існує задача визначення кількості пільговиків. Це обумовлено тим, що різні пільги по-різному ставляться до членів сім'ї абонента. Наприклад, деякі застосовуються тільки для пільгування одного пільговика, інші - на чоловіка і дружину, треті - на всю сім'ю. У свою чергу, родичі також можуть мати права на пільги. І при звичайному складання кількість пільговиків може перевищити загальне число людей, що проживають в квартирі. Для розрахункового варіанта визначення кількості пільговиків потрібна наявність інформації про всіх членів сім'ї абонента та їх родинних відносинах кожен з кожним. З іншого боку, це завдання досить проста для вирішення її контролером ділянки: при будь-яких змінах у складі сім'ї він просто вказує кількість пільговиків для кожної позиції зі списку пільг особового рахунку.
Завдання розрахунку пільг також ускладнює можливість початку дії пільги і її закінчення в будь-який день звітного періоду.
Перерахунки пільг здійснюються за допущені помилки, як в розрахунку пільг, так і у визначенні кількості та вартості послуг. Перевіркою правильності розрахунку є звіт, в якому вартість послуг та надані пільги групуються не звітних періодів, а по розрахунковим. Тобто, наприклад, звіт про виконані нарахування та наданих пільг за січень, не залежно від того, в якому місяці ці нарахування або коригування були виконані. У практиці роботи підприємств ЖКГ буває завдання масового перерахунку пільг. Такі дії обумовлені тим, що влада іноді затримують публікацію законів про нові пільги або про скасування існуючих.
Ще одна сторона обліку пільг - це бюджетні гроші, тому вони контролюються державними органами. Крім періодичних перевірок, ці органи вимагають надання інформації у друкованому або електронному вигляді про хід нарахування за послуги та розрахунку пільг. Для підтвердження правової основи нарахування пільг, у постачальника в базі даних зберігаються всі реквізити відповідних документів. На жаль, очевидне завдання, зберігання відсканованих копій документів у цій же базі даних, ні в одній з зустрілися систем не згадується. Тому, мабуть, самі копії документів знаходяться у шафах, що стоять поряд з робочими місцями контролерів.
Облік субсидій на послуги, що надаються
Багато систем у переліку своїх можливостей містять пункт «можливість розрахунку субсидій». Для цього зберігають дані про склад сім'ї, доходи, мають спеціальні процедури і т.п. На мій погляд, це зайві функції для систем ЖКГ, тому що для такого розрахунку, по-перше, немає відомостей про вартість комунальних послуг, що надаються безліччю інших постачальників, і, по-друге, право на надання субсидій є винятковим для державних служб. Тому в зону інтересів інформаційних систем ЖКГ входить тільки облік отриманих субсидій та надання даних у відповідні служби про своїх абонентів. Ті служби збирають такі дані зі всіх постачальників комунальних послуг міста, також вони збирають необхідні документи від абонентів, і призначають їм субсидію. Ці служби відповідають за правильне нарахування субсидій. І для цих служб є свої системи для роботи з субсидіями.
А в системах ЖКГ залишаються тільки функції обліку та контролю:
- Введення (імпорт) отриманих субсидій;
- Відстеження платіжної дисципліни абонентів, які отримують субсидії
надання даних для розрахунку субсидій у відповідні служби
Оплата
Введення оплати або імпорт її з банківських програм або систем РКЦ супроводжується вирішенням кількох завдань:
- Облік за видами оплати;
- Розподіл безадресної оплати між різними видами послуг.
- Облік оплати безготівкової оплати по банках
Облік за видами оплати вимагає розсортувати оплату, отриману по касі, безготівковим платежем, від банків, шляхом заліків. Це потрібно для бухгалтерії підприємства при виконанні бухгалтерських проводок. Точніше для звірки з бухгалтерськими проводками.
Розподіл безадресної оплати - це неприємна реальність, з якою доводиться рахуватися. Якщо у постачальника ведуться обороти по кожному виду послуг окремо, а абонент при оплаті не вказав, за яку послугу він платить, то розподілом доводиться займатися операторам постачальника послуг. Програмне забезпечення автоматизованих систем при вирішенні цієї задачі грунтується на наборі різних імпіріческіх правил, наданих користувачами системи.
Облік оплати по банках, з якими укладено договори на прийом платежів, потрібно для того, щоб розібратися з комісійними, які банки зараховуються собі за послуги з прийому платежів. Власне потрібна інформація про те, скільки грошей, судячи з квитанціями абонентів, має прийти з якого банку. Далі ця інформація передається в бухгалтерію і порівнюється з її даними.
Обороти
Це стандартна завдання обліку залишків на початок і кінець місяця, дебету і кредиту за звітний період.
Розрахунок і нарахування пені
Посилання на таку можливість зустрілася тільки в одній системі. Розрахунок пені при роботі з населенням - це складне і не вдячна справа. Складне, бо сам механізм розрахунку пені представляє собою складне завдання для програмування. А невдячна тому, що розмір цієї пені та бажання абонентів її сплатити не варті тих коштів, які витрачаються на організацію цього виду діяльності.
Юридична служба
Є кілька завдань, що знаходяться у сфері дії інформаційних систем для ЖКГ. Перш за все, це завдання підготовки матеріалів для судових позовів. Система надає список тих абонентів, на яких «пора подати до суду». А для кожного абонента - позовну заяву і додаток до нього, що містить історію утворення і погашення боргу. Судові справи ставляться на облік. Інформаційна система відстежує хід виконання судових рішень. Власне у них є три стадії - подача позовної заяви, прийняття рішення, відстеження платежів держмита і основного боргу. Різні звіти надають дані про хід цієї роботи. А процедури вибірки чергового складу «жертв» контролюють наявність вже існуючих справ, щоб не повторюватися.
Цікаво, що для підготовки списку на оформлення позовних заяв програмним забезпеченням можуть використовуватися спеціальні психологічні прийоми. Наприклад, за об'єктивних обмеженнях на кількість позовних заяв, що подаються в один звітний період, система може запропонувати по одному мешканцю з кожного будинку, або по одному з кожного під'їзду будинку. Чутка про притягнення до суду розходиться по сусідах, і в наступному звітному періоді таких абонентів стає чомусь менше.
Друге завдання для юристів - це облік різних договорів з абонентами. Одним з таких договорів є договір на погашення боргу. Суть його полягає в тому, що абонент зобов'язується за певну кількість місяців звести свій борг до нуля. Або іншими словами, кожен місяць його борг буде зменшуватися на певну суму. Робота юриста з такими договорами полягає в тому, що їх укласти, роздрукувати, і потім контролювати правильність його виконання.
Звіти
Існує маса звітів, що формуються інформаційними системами ЖКГ. Наприклад, квитанції на оплату, відомості розрахунку послуг, оборотно-сальдові відомості, списки пільговиків і субсидій, реєстри пільговиків, звіти з оплати та заборгованості та ін Формування звітів по нарахуваннях, оплаті, заборгованості, субсидіях. Формування та друк платіжних документів з оплати житлово-комунальних послуг в різних варіантах, оперативна звітність в необхідних розрізах (оборотно-сальдові відомості по нарахуваннях, оплаті, заборгованості та інші звітні форми), статистична звітність, формування зведених відомостей.
Окрема група звітів призначена для роботи з неплатниками:
- Видача попереджень, приписів, повідомлень, актів звірки з підрядниками;
- Відслідковування простроченої заборгованості.
Можна було б якось структурувати ці звіти, але не зрозуміло навіщо. Набрати такий склад звітів, який би задовольнив усі випадки життя не можливо. Тому практично всі розробники сходяться в тому, що система для ЖКГ повинна мати вбудований механізм управління звітами: угруповання, коригування існуючих звітів і створення нових.
Банки
Пункт прийому платежів
Від програмного забезпечення для касира потрібно насамперед максимальну зручність у роботі. Коли у нього за склом стоїть черга, йому ніколи перекладати руку з клавіатури на мишку, шукати покажчиком кнопку, і потім нести руку назад, що б набрати деяке число. Все повинно виконуватися клавішами, максимально швидко.
Друге, касир хоче, що б у нього була лише одна програма на комп'ютері. Спроби різних постачальників, не пов'язаних між собою єдиною системою, поставити кожен свою програму в пункт прийому платежів, призводять до додаткового навантаження на оператора під час прийому платежів і після закінчення робочої зміни при обробці даних. Тому ця програма має можливість приймати платежі не тільки для підприємств ЖКГ, а й для інших одержувачів (бюджет, БТІ, переклади і т.п.)
Сьогоднішня інформаційна система приймає інформацію від єдиного розрахункового центру або з бухгалтерії банку про нарахування за поточний місяць по кожному виду послуг кожного постачальника. Ідентифікація споживача послуг здійснюється за допомогою пластикової карти, за кодом особового рахунку на квитанції або шляхом пошуку за прізвищем і адресним реквізитами абонента. Абонентові надається список всіх комунальних підприємств, яким він повинен заплатити гроші, і сума боргу. Отримана від абонента сума розподіляється між одержувачами або автоматично, або оператором за вказівкою платника. Квитанція про оплату містить всі необхідні відомості, які можуть знадобитися при звірці платежів з постачальниками послуг.
Система фіксує факт і суму оплати в системі. Фіскалізація виконується або на апаратному рівні (касовий апарат, фіскальний принтер), або на програмному рівні (протокол дій касира, доступний для перегляду бухгалтером банку). Після закінчення робочої зміни формується касовий звіт. Дані про отримані платежі передаються в бухгалтерію банку, в єдиний розрахунковий центр, якщо він використовується в системі, і постачальникам послуг (одержувачам платежів). Оскільки система працює з конфіденційними даними, вона включає в себе систему безпеки, а саме перевірку переданих та отриманих даних на достовірність, контроль змін всіх операцій, авторизації і розмежування доступу користувачів до операцій і навіть до окремих частин даних. Застосовується шифрування, як переданої інформації, так і самої бази даних.
Бухгалтерія банку
Завдання бухгалтера банку в роботі з платежами населення - зібрати їх з усіх пунктів прийому, об'єднати, видати звіти для кожного одержувача платежів і зробити банківські проводки. Для виконання банківських проводок його модуль системи ЖКГ має можливість експорту проводок в банківську систему «операційний день». Налагодження прямої інформаційного зв'язку з банківською системою практично виключена вимогами безпеки.
Програмне забезпечення банку також містить засоби для ведення договорів з постачальниками послуг. Основним параметром договору є розмір комісійних банку і спосіб їх отримання. Прикладами способів утримання комісійних є: c кожного платежу, за підсумками місяця. Величина комісійних розраховується автоматично та використовується для генерації банківських проводок.
Якщо в системі платежів не використовується розрахунковий центр, то на бухгалтера банку лягає завдання узгодження кодів особових рахунків. У нього є таблиця відповідності: код абонента в банку - код у постачальника послуг. Така відповідність потрібно для обміну інформацією з постачальниками послуг.
ЖЕКи
ЖЕК, з одного боку, виступає в системі ЖКГ як постачальник послуг, а з іншого - як місце обліку населення. Як постачальник послуг йому властиві всі ті функції, що і для всіх інших постачальників послуг. Тут розглянемо ЖЕК, як місце обліку населення.
Реєстрація населення
Реєстрація населення здійснюється відповідно до вимог законодавства. Це надає ряд наступних можливостей:
- Облік поквартирних та реєстраційних карток;
- Ведення реєстру населення;
- Ведення архівів реєстраційних записів;
- Формування всіх видів довідок;
- Формування необхідної звітної документації.
Паспортний стіл (Якщо він входить до складу ЖЕК)
Вирішуються такі завдання:
- Прописка та виписка (листок прибуття, листок вибуття);
- Формування списку мешканців, виборців;
- Довідка про склад сім'ї, про реєстрацію іноземного громадянина, про вільну житлоплощі і ін довідки,
- Звітність в різні служби
Інформація для постачальників послуг
Як місце обліку населення, ЖЕК має самої свіжої інформації про склад і рух населення. Така інформація вкрай необхідна для постачальників послуг, у яких кількість і вартість надаваних послуг залежить від кількості мешканців. Наприклад, вибуття мешканця, у якого є пільга, має одразу бути враховано при розрахунку пільг. Це знають всі, в тому числі перевіряючі ревізори. Вони приходять на перевірку вже зі списком пільговиків, наприклад, померлих протягом кількох останніх звітних періодів. Якщо немає оперативної передачі інформації з ЖЕКів, то у постачальника послуг її ще немає. У родичів вибулого таким чином мешканця не є першою необхідністю надання такої інформації постачальнику послуг. Результат перевірки - штрафи на підприємство та адміністративні покарання контролерів.
Ось чому інформаційна система ЖЕКу повинна містити засоби передачі даних в розрахунковий центр або безпосередньо постачальникам послуг. Така інформація коштує грошей. І постачальники послуг готові платити ці гроші за цю інформацію.
Розрахунково-касовий центр (РКЦ)
Роль розрахункового центру - організація всієї системи платежів в масштабах міста. Функціональні можливості його програмного забезпечення призначені для вирішення цього головного завдання:
прийом інформації про нарахування за послуги від зовнішніх організацій;
видача інформації в банки про стан особових рахунків громадян;
реєстрація банківських виписок по платежах населення;
прийом готівкових платежів та зарахування їх на особові рахунки громадян;
надання інформації громадянам про величину, характер нарахувань за надані послуги та поточному сальдо на їх особових рахунках через спеціалізовані термінали;
видача інформації одержувачам платежів про прийняті платежі;
прийом інформації з банків про платежі населення;
можливість роботи з організаціями - безготівковими платниками (підприємствами, що оплачують житло своїм співробітникам)
зв'язок з відділами субсидій, управлінням соціального захисту населення та іншими органами державного контролю;
прийом їх паспортного столу;
інформація про рух квартиронаймачів.
До попутним завдань відносяться: прийом населення та виконання розрахунків відповідно до кількості і вартістю послуг замість постачальників цих послуг.
Прийом населення можливий завдяки тому, що на розрахунковому центрі є вся інформація про стан нарахувань і платежів за комунальні послуги.
Для зменшення навантаження на операторів єдиного розрахункового центру встановлюються термінали. Споживач послуг за допомогою терміналу має можливість отримувати інформацію про стан свого особового рахунку шляхом зчитування карти. Інформація надається на чеку. За допомогою терміналу квартиронаймач має можливість розрахувати суми нарахувань за показниками лічильників. Для цього йому слід вважати в терміналі свою пластикову карту, вибрати види послуг (холодна вода, гаряча вода), ввести їх кількість і надрукувати чек із сумами оплати за кожну послугу і підсумкову суму за всі послуги. Термінал може встановлюватися на пункт прийому платежів.
Виконання розрахунків по послугах дозволяє включити в комплексну систему тих дрібних постачальників послуг, для яких організація такого робочого місця у себе є не рентабельною. Зазвичай ці послуги мають прості алгоритми розрахунку. Спроби організації розрахунків для таких постачальників, як тепловики, газсбит, водоканал тільки ускладнюють роботу служб збуту цих підприємств. Це пояснюється тим, що у них є дуже багато нюансів при розрахунку кількості та вартості послуг, що б доручити цю роботу непрофесійним фахівцям, що мають відповідне технічну освіту і досвід роботи. Зазвичай на розрахунковому центрі таких немає. Тому завдання розрахунку кількості та вартості послуг краще таким постачальникам виконувати самим, а результати передавати на розрахунковий центр. За розрахунковим центром ж залишити тільки функції організації платежів.
Є ще одна функція інформаційних систем розрахункового центру, про яку чомусь в рекламних оголошеннях постачальники програмних рішень замовчують. Це функція погодження кодів особових рахунків для постачальників, знову йдуть на систему. Коли потрібно зіставити коди особових рахунків з двох баз даних, кількість яких становить кілька десятків тисяч, то рішення цього завдання «в лоб» може зайняти не допустимо тривалий період. Для узгодження використовується спеціальне програмне забезпечення, що дозволяють виконати його поетапно, працюючи на кожному етапі з доступним для огляду безліччю записів. Таке узгодження використовує додаткові ознаки, що мають ієрархічну структуру. Найбільш підходящим є система адрес. Наприклад, на першому етапі узгоджуються коди вулиць. На другому - номери будинків. Як не дивно, але їх також треба узгоджувати, тому що в різних базах даних вони можуть мати різний формат, особливо для різних приставок, таких як «а», «б», «корпус», «блок» і т.п. За умови погодження вулиць для кожної вулиці створюється таблиця, в якій більшість будинків узгоджені автоматично, а інші відзначені для коригування оператором. На третьому рівні виконується узгодження особових рахунків. Для кожного будинку створюється таблиця або ділянку в таблиці для вулиці, в якому програма виконує узгодження більшості особових рахунків за номером квартири, а решта відзначає для ручного коректування оператором.
Установи влади
З переглянутих систем отримано не дуже багато інформації. Модуль інформаційної системи ЖКГ, що знаходиться в установах влади, повинен містити підсумкові дані про виставлені платежі, про суму оплати, про суму поточної заборгованості. Можливо, що цей модуль повинен бути пов'язаний не з розглянутої системою ЖКГ, а з міською системою управління житлово-комунальним господарством, тому що з боку влади підприємства ЖКГ представляють інтерес в узагальненому вигляді. Навряд чи їм знадобиться інформація про окремо взятих абонентах.
3. Огляд рішень автоматизації в ЖКГ: Технічні аспекти та вартість
У попередніх частинах були розглянуті склад учасників автоматизованої системи ЖКГ та її функціональні можливості. Дана частина огляду присвячена питанням, які пов'язані з технічною і фінансовою стороною впровадження та експлуатації інформаційних систем для ЖКГ: як вони створюються і впроваджуються, а так само: скільки коштує їх впровадження і використання.
Технічні аспекти
Перш за все, розглянемо технічні аспекти створення та експлуатації автоматизованих систем ЖКГ: засоби програмування, побудова баз даних, засоби зв'язку між учасниками.
Засоби програмування
Загальний перелік засобів програмування, що використовуються для розробки комплексних систем або окремих програм ЖКГ, можна викласти однією фразою: використовуються всі мови програмування, які застосовувались протягом останніх 10-15 років, і все, що існують зараз.
За підходу до побудови програмного забезпечення системи явно діляться на дві групи: для місцевого використання та програмні продукти.
Програмне забезпечення першої групи призначено для вирішення завдань ЖКГ на тому підприємстві, на якому працюють програмісти, його розробили, впровадили й супровідні. Воно не призначене для продажу. Тому не володіє необхідними атрибутами програмних продуктів, зокрема, засоби розвитку, документація, інсталяція, засоби підтримки оновлень, контроль цілісності бази даних, діагностика дій користувачів, система підтримки розробником ... Це програмне забезпечення працює «по-російськи» - у присутності програміста - його автора.
Більшість систем, в тій чи іншій мірі відповідають вимогам пропонованих продуктів, використовують у своїй основі інструментарій, не тільки прискорює процес створення, але і дозволяє виконувати супровід системи на місці її експлуатації практично без участі розробників. З розглянутих систем, найбільш поширений інструментарій - це 1С. Але системи, створені на основі цієї технологічної платформи, знову ж таки з розглянутих в огляді, мають досить обмежені функціональні можливості і застарілі засоби зв'язку між окремими модулями. Найчастіше - це автоматизація однієї з ділянок ЖКГ, а у зв'язках застосовується експорт / імпорт даних.
Комплексні системи, які включають в себе більшість функцій, перелічених у другій частині огляду, побудовані на основі інструментарію, створеного авторами цих же систем. Тут використовуються розподілені бази даних, електронні зв'язку між серверами, конструктори екранних форм, генератори звітів. Зв'язки застосовуються на різних рівнях - модеми, виділені лінії, Інтернет. Також вони дублюються можливістю експорту / імпорту даних.
Засоби програмування дозволяють програмістам супроводу корегувати існуючі процедури обробки даних і додавати нові. У тиражних системах вони є відкритими.
Бази даних
Аналізуючи побудову баз даних, використовуваних для зберігання і обробки інформації в системах ЖКГ, виділяємо два моменти: основа побудови та територіальне розташування.
Найбільш стара і найбільш широко використовувана основа для бази даних - це dbf-файли. Причиною її розповсюдження, мабуть, є їх повсюдне використання в недалекому минулому - 90-ті роки минулого століття і початок 21-го. У той час вони задовольняли потреби розробників, так як вирішувалися в основному локальні завдання, а таблиці баз даних становили десятки або кілька сотень тисяч записів. Але для сьогоднішніх комплексних автоматизованих систем вони не підходять з двох основних причин: обмежена кількість записів в одній таблиці і недостатня надійність.
Прояв першої проблеми полягає в тому, що при настанні певної межі кількості записів і роботі з індексними файлами запис даних може відбуватися в довільне місце таблиці. Особливо це ймовірно при спільному доступі до файлу. Друга причина виражається в невідповідності індексних файлів і основної таблиці даних. Ця невідповідність може відбутися з різних причин. І головна проблема в тому, що помітити його можна тільки при візуальному перегляду інформації - невідповідність зчитувальних даних. Є також інші причини, через які файлова система у знову створюваних системах вже не використовується. Не будемо їх тут перелічувати.
Сучасні бази даних побудовані на основі клієнт - серверних технологій. Існують різні системи управління базами даних, що володіють своїми достоїнствами і недоліками. Кожна з них використовується хоча б в одній системі, призначеної для автоматизації ЖКГ. Найбільш поширеною є MS SQL 2000. Пояснити це можна, мабуть, її спорідненістю з найбільш поширеною операційною системою персональних комп'ютерів - Windows. Далі по популярності йде Interbase. Також, напевно, тому, що це рідне засіб для роботи з базами даних для програмістів, що використовують Delphi, один з найбільш популярних програмістських інструментів початку десятиліття. А може бути тому, що фірма Борланд в той час запропонувала безкоштовну версію Interbase. Є також реалізації бази даних ЖКГ під управлінням Oracle, однією з найбільш розвинених, але дорогих і громіздких систем управління базами даних.
Слід відзначити також тенденцію постачальників систем управління базами даних, спрямовану на поширення їхніх програмних продуктів - пропозиція безкоштовних версій з певними обмеженнями, в які вписуються не великі і не багаті користувачі, до яких відносяться ЖЕКи і пункти прийому платежів. Прикладом таких систем є MSDE 2000, MSDE 2005 корпорації Microsoft.
Найбільш проста топологія бази даних - це розташування всієї інформації на одному сервері. Клієнти підключаються по віддалених лініях і вирішують свої поточні завдання. Очевидні недоліки - необхідність постійного зв'язку, повільна швидкість передачі даних. Однак ці недоліки з часом стає все менш суттєвими - лінії зв'язку стають все більш швидкодіючими і все менш дорогими.
Інший варіант реалізації - розподілена база даних по всіх або по частині учасників ЖКГ. Вона позбавлена недоліків попередньої топології, але має свій - необхідність синхронізації даних.
Синхронізація даних ведеться різними способами. Найбільш поширений - експорт / імпорт. Дані на носії або по електронній пошті переміщуються між учасниками ЖКГ. У цьому істотний вплив на працездатність системи має людський фактор - все треба робити під час і дуже акуратно.
Другий рівень синхронізації - обмін даних між модулями системи шляхом зв'язку з віддаленими серверами. Цей обмін викликається або по команді користувача, або за заданим розкладом. Він полягає в тому, що деяка процедура на одному з пов'язаних серверів «зчитує до себе» або «записує до нього» необхідні для синхронізації дані.
І, нарешті, найбільш високий рівень - синхронізація баз даних шляхом реплікацій. Ці засоби дозволяють змінювати дані як на одній стороні лінії зв'язку, так і на іншій. За заданим розкладом або по команді користувача сервера з'єднуються і виконують синхронізацію баз даних.
Вартість
Про вартість також можна сказати однією фразою: від нуля до нескінченності. Різні фірми-постачальники, впроваджувача пропонують абсолютно різні ціни на свої програмні продукти і на послуги з впровадження та супроводу. Ціна залежить, звичайно, від функціональних можливостей системи, але це не однозначна залежність. І є великі шанси знайти систему більш дешеву і більш придатну для запуску в експлуатацію і використання, ніж та, що пропонується який-небудь розкрученої фірмою.
У витратах на автоматизацію ЖКГ, так само як і для будь-якої іншої управлінської системи, є кілька складових: прикладне програмне забезпечення, системні засоби, витрати на введення в експлуатацію та супровід.
Вартість прикладного ПЗ
Прикладне програмне забезпечення - це безпосередньо та програма, яка вирішує поставлене завдання - у нашому випадку автоматизація ЖКГ. Його вартість залежить від цінової політики постачальника: або фіксована, або збільшується із зростанням кількості робочих місць користувачів, або зростає зі зростанням кількості особових рахунків, що обробляються в системі.
Практично немає залежності ціни від якості системи: функціональної повноти, її надійності, простоти в експлуатації. Але є дуже сильна залежність від «торгової марки». Фірми, що мають довгий послужний список, дозволяють собі встановити ціну на свої продукти набагато вище, ніж початківці.
Вартість системних засобів
Це ті витрати, які часто не вказуються у вартості автоматизації. До них відносяться витрати на операційну систему, офіс, засоби зв'язку і т.п. Необхідність у таких витратах істотно залежить від політики споживачів у сфері ліцензування програмного забезпечення.
Особливо в цих витратах може виділятися вартість системи управління базою даних. Наприклад, оголошується ціна на програму $ 200, при цьому в технічних характеристиках указується, що ця програма використовує СУБД, вартість якої становить $ 10000. Тому при покупці програмного забезпечення для автоматизованої системи треба завжди враховувати цей бік витрат.
Витрати на впровадження
Наступна складова витрат - це запуск системи в експлуатацію. Тільки елементарні іграшки встановлюються протягом декількох хвилин і відразу починають працювати.
Впровадження автоматизованої системи пов'язано з різними доробками, навчанням користувачів, завантаженням бази даних. Все це вимагає часу спеціалістів, як своїх, так і залучених. А час фахівців коштує грошей. Час на доопрацювання залежить від функціональної повноти системи та рівня кваліфікації тих фахівців, які її виконують. Час на навчання залежить від простоти системи і, знову ж кваліфікації користувачів системи. Час на завантаження бази даних залежить від її наявності в електронному вигляді, стану, і знову від кваліфікації фахівців, що виконують завантаження.
Витрати на супровід
Складні технічні системи вимагають підтримки. Найбільш очевидною завданням є доопрацювання до мінливих умов експлуатації. Інше завдання - надійність роботи. Такі функції як: архівування даних, відновлення даних, вірогідність збоїв в цілісності бази даних залежать від рівня розробки програмного забезпечення, по-іншому, від її якості.
При низькому рівні для супроводу системи потрібні послуги фахівців. І, чим слабкіше система, тим більш трудомісткий процес супроводу.
Таким чином, при виборі системи, необхідно проаналізувати всі складові витрат, оцінити час і гроші, необхідні на виконання всіх етапів автоматизації в сукупності. Цілком може виявитися так, що більш дороге програмне забезпечення дозволити здійснити автоматизацію з меншими сукупними витратами, ніж дешевші.
Висновок
Функціонал інформаційних систем ЖКГ, викладений в роботі, не претендує на повноту. Напевно, щось пропущено, а що-то викладено надто оптимістично. Але якщо б була така одна система, яка могла б усе це робити, та ще якщо б вона була доступна за вартістю її впровадження та експлуатації, то автоматизація ЖКГ почала б рухатися з прискореними темпами.
У роботі використаний матеріал з різних сайтів і описів систем постачальників, а також форумів, на яких є їх обговорення. Є дуже багато систем. Їх не можливо перерахувати всі. У кожній з них є своя родзинка, щось, що заслуговує на інтерес. Тому в роботі викладені лише загальні їх риси, властиві багатьом системам, або ті рішення, які були цікаві з технічної та практичної точки зору, навіть якщо вони не достатньо апробовані.