“Відкриті” або “закриті” програми – ось в чому питання, Комерція, Різне, статті

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


Західні програми гранично закриті і повністю готові до експлуатації відразу після покупки. Вітчизняні ж реалії абсолютно протилежні – “користувач може змінити в цих продуктах майже всі, тобто фактично розробити новий. У половині АСУП для цього застосовуються стандартні мови програмування, в інших використовуються власні кошти, що аж ніяк не спрощує освоєння програм … “*. Іншими словами, користувач, купивши таку програму, повинен її доводити до потрібного йому рівня. На жаль, ніколи цю тему не розвивають, відзначають лише, що ця сьогоднішня наша особливість “… була характерна для західних АСУП в середині 80-х – на зорі появи ПК на робочих столах більшості бізнес – користувачів “*. Не можемо не погодитися з такими твердженнями. І тему цю хочемо розвинути …


Відкритість програми повністю знімає відповідальність розробника за її правильне функціонування. Жоден розробник ніяких претензій за помилки в роботі програми приймати не буде, якщо програма була змінена користувачем. Якщо користувач хоч раз змінить програму (а для цього “відкритість” і потрібна) – розробнику вже можна не дзвонити … Користувач після цього залишається зі своєю системою в повній самоті, Багато чого з того, що розробник пише в ліцензійній угоді про свою відповідальність, втрачає сенс. Мені не відомий жоден розробник, який би декларував готовність відповідати за програму, що піддалася змінам з боку користувача. При цьому, розробники, розхвалюючи “відкритість” програми, ця обставина старанно замовчують.


Відкритість програми позбавляє користувача можливості використовувати нові версії програми, які випускає розробник. Припустимо, розробник випустив потрібну користувачеві відкриту програму. Назвемо її Р-1 (версія 1 від розробника). Користувач змінив її (саме для цього призначена відкритість) і тепер має в своєму розпорядженні вже іншою програмою. Назвемо її П-1 (версія 1 від користувача). Минув час. Змінилося законодавство (або розробник виправив помилку, або просто допрацював) і розробник випустив нову версію. Назвемо її Р-2 (версія 2 від розробника). Відповідно до раніше даними обіцянками (При продажу Р-1) розробник готовий надати свою нову версію всім старим користувачам (безкоштовно або зі знижкою). Але що буде робити з цією новою програмою користувач? Якщо він замінить свою програму П-1 на Р-2, то повністю втратить всі свої напрацювання (а вони йому потрібні)! Якщо він не замінить П-1 на Р-2, то йому не будуть доступні нові можливості від розробника (але й вони потрібні)! У користувача є тільки два шляхи – або з кожною новою версією від розробника заново вносити всі раніше зроблені зміни (знову наймати програмістів, а це витрати, тестування, помилки …) або назавжди відмовитися від нових версій, в т.ч. у випадках зміни законодавства та виправлення грубих помилок. Іншими словами, якщо користувач проковтнув наживку і зайнявся зміною відкритої програми, то нові версії від розробника практично йому будуть марні. Користувач повинен буде все супроводу програми здійснювати самостійно. При цьому ніхто нікого не обманював. Розробник надав кошти зміни програми, користувач ними скористався, розробник запропонував нові версії. В результаті страждає користувач. Розробнику тільки користь – він звільнився від раніше даних зобов’язань!


За умови поставки закінченого рішення відкритість програми залишається незатребуваною. Всі розробники декларують підтримку законодавства. Але підтримка і повна підтримка це різні речі. При реалізації повної підтримки виникає ситуація коли відкритість програми просто не потрібна! Розробники відкритих програм надають користувачеві можливість робити нові документи, нові схеми проводок і т.п. Передбачається, що користувач може захотіти зробити документ, не передбачений законодавством, або зробити проводку, не передбачену законодавством, або розраховувати податки способом, не передбаченим законодавством. Я багато разів просив прихильників відкритих програм надати мені приклад типової операції або документа, які були зроблені користувачами і при цьому суперечили законодавству. Жодного прикладу не отримав. І не сподіваюся вже. Суть в тому, що відкритість програми потрібна не користувачеві, а розробнику! Розробник намагається (і небезуспішно!) Перекласти виправлення своїх недоробок (тобто свого шлюбу!) на плечі користувача. Хто з розробників “відкритих” програм може сказати, що його програма (конкретну назву!) Реалізує [українське, російське, білоруське] законодавство повністю?


Причина появи відкритих програм – нездатність розробника на 100% реалізувати в своїх програмах підтримку поточного законодавства і організувати процес повного відстеження його змін. Розробник перекладає доопрацювання своїх програм на плечі і гаманець користувача, називаючи цей процес мудрованими термінами, як, наприклад, облік специфіки та настроювання на конкретні потреби. Як тільки користувач задасть собі питання на кшталт “а в чому, власне, специфіка зробленої на моє замовлення (і за мої гроші) доопрацювання – це ж реалізація цілком стандартною і законній господарській схеми …?” або “а чому система не підтримує цю стандартну і законну схему господарювання? “, то відразу розсипаються всі аргументи на користь відкритості програми.


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


Відкрита програма це дуже дорого для користувача. Весь сенс відкритості полягає в необхідності для користувача програмувати. Експлуатація “відкритої” програми вимагає від нього або містити своїх програмістів (а це необхідність платити зарплату), або періодично користуватися послугами третіх фірм. Причому витрати при цьому дуже великі. І дуже важливо те, що, заплативши фірмі розробнику за програму, користувач повинен звертатися за послугами до фірм, які йому нічим не зобов’язані. Користувач платить одним, а за допомогою повинен звертатися до інших. Розробнику це дуже вигідно: гроші отримані, а відповідальності немає. Вигідно це і настройщик – він нічим користувачеві не зобов’язаний і тому має право за послугу брати гроші. І бере! І ніщо настройщик не заважає відмахнутися від особливо докучливих користувачів. І ніщо йому не заважає припинити відносини з користувачем, у якого виникли серйозні проблеми. Виникає ситуація, коли споживач разом з програмою не може придбати відповідальність постачальника.
Постачальники “відкритих” програм дуже не люблять спроб з’ясування т.зв. сукупної вартості володіння їх системами. Численні “порівняльні аналізи програм”, які часто публікуються в різних виданнях, ніколи не аналізують цю вартість! Причина в тому, що розробник не хоче показувати реальну ціну (з причини її високого значення) і не може вказати занижене значення – відразу виникають незручні питання … (Як просто в разі закритих систем: “цей телевізор коштує стільки, а цей стільки …”, “цей текстовий редактор стільки, а ось той трохи більше …”)


Відкрита програма змушує користувача реально купувати не те, що він вирішив купувати. Користувачеві потрібні прикладні програми. Всі ці нудні “створення накладних”, “облік термінів придатності товару” і т.п. Але часто він змушений замість цього купувати засіб програмування, до якого додаються в якості безкоштовного “бонусу” типові прикладні рішення. Але користувачеві саме цей “бонус” і потрібен! А гроші то сплачені за інструмент. І відповідає розробник за функціонування інструменту, але не прикладних програм. І дзвонити розробнику (користуватися безкоштовними телефонними консультаціями) можна тільки за питань функціонування інструменту. І претензії пред’являти (пам’ятаєте у Райкіна: – “… гудзики добре пришиті? …”) Нікому!
Відкрита програма породжує юридичні проблеми. Ситуація коли платити треба одному, а відповідальність вимагати з іншого, коли купуєш одне, а реально отримуєш інше, неминуче породжує правову невизначеність. Які гарантії у споживача? Від кого їх вимагати? Що робити в тому чи іншому випадку? Куди телефонувати, а куди не треба? Всі ці питання розробники “закритих” програм відображають в т.зв. “Ліцензійному угоді “. (Усі, хто встановлював” коробкові програми “стикалися з текстом і кнопочками” приймаю умови “і” не приймаю умови “- це і є” Ліцензійну угоду “. Дуже часто знаходиться в коробці і паперовий варіант цього документа.) А що робити розробникам “відкритих” програм? В юридичному документі треба викласти все “як є” (а “Ліцензійну угоду” – це юридичний документ). Але все “як є” розробник писати не хоче! Навіщо відкривати очі користувачеві! І залишається: чи займатися грою слів, або, в “особливо складних випадках”, не надавати користувачеві ліцензійної угоди взагалі! Ніхто ніколи не замислювався, чому постачальник не укладає ліцензійної угоди зі споживачем своєї продукції? Хто може привести приклад західної “коробкової” програми без ліцензійного угоди? Тобто взагалі без ліцензійної угоди! А ось на українському ринку програм для “автоматизації підприємств” це запросто …


Мушу зазначити, що читання “ліцензійних угод” від розробників “відкритих програм” може дуже потішити! Особливо, якщо читати ці документи в режимах “осмислення” і “читання між рядків” … Насмілюся порекомендувати власникам (і потенційним власникам) “відкритих” програм почитати уважно відповідні “ліцензійні угоди”. Це повчальне заняття …


Та й ситуація, коли розробник гордо ставить знак захисту авторських прав (copyright) на своїй програмі і відразу ж провокує користувача цю ж програму самостійно змінювати (але “copyright” саме це робити забороняє!), виглядає суперечливо і юридично безграмотно. Або для кого безграмотність, а для кого передбачливість? Адже при найменшій зміні такої програми користувач автоматично стає порушником закону!
Але, що буде, якщо споживач покупку буде здійснювати в компанії з юристом?


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


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


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


Відкритість програми не дозволяє якісно вносити модифікації в програму при зміні законодавства. Але часто прихильники відкритості стверджують зворотне. Всі зміни, що вносяться в закриту програму, завжди виробляються фахівцями фірми розробника. Це їхня робота. Вони знають вихідні тексти програми, її архітектуру, особливості. У них є досвід виконання такої роботи. Це штатні програмісти фірми розробника. У разі відкритої програми картина інша. Зміни часто роблять випадкові люди, які не мають відповідного досвіду і можливостей. Та й робота ця часто носить характер халтурки … Неминуче наслідок – якість модифікацій закритої програми незрівнянно вище якості модифікацій відкритої програми.
Є нелогічність і в іншому. Припустимо, що відбулася зміна законодавства. Розробник закритої програми виробляє відповідні зміни і поширює нову версію програми. У випадку відкритої програми на території країни одночасно проводяться одні і ті ж зміни однієї і тієї ж програми, але різними людьми і різними способами. Вся економічна логіка каже, що такий стан речей для відкритої програми не може обходитися дешевше централізованого зміни для закритої програми. І зайві витрати неминуче оплачуються споживачем.


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


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


У разі відкритої програми користувач залежить від розробника нітрохи не менше, ніж у випадку закритої програми. Прихильники концепції “відкритості” програми часто вказують на залежність користувача від фірми розробника. Мовляв, перестане існувати розробник, і нікому буде супроводжувати програму. Так. Це так. Але і в разі “відкритої” програмі не можна сподіватися на “життя програми” після “смерті” розробника. Якщо платформа перестане супроводжуватися, то чи довго “настроювачі” зможуть і захочуть мати справу з програмою-трупом?


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


У всякому разі, розмір втрат при зникненні розробника “закритої” програми дорівнює її ціні. Хто порахує розмір витрат при експлуатації “відкритої” програми? Всі ці численні договору по обслуговуванню і “налаштування на специфіку” і “змінюється законодавство” …


Часті зміни законодавства не перешкоджають експлуатації закритих програм. Нерідко доцільність “особливого національного шляху” в обговорюваному питанні обгрунтовують нібито частими змінами законодавства. Мовляв, у нашій країні такий потік змін законів, що наші фірми-розробники, на відміну від західних, не можуть вчасно робити зміни. Як наслідок висновок про необхідність “відкритості” програми. У нас є заперечення:
Західні реалії в цьому відношенні нітрохи не краще наших. Зміни законів там теж дуже часті. Переконатися в цьому дуже легко, відвідавши сайти, які обслуговують західні програми. Календар виходу змін дуже і дуже щільний … Але при цьому західні фірми розробники цілком управляються із завданням відстеження мінливого законодавства. І справа, мабуть, не в законах, а в ставленні до справи з боку розробників програм.


Припустимо, що дійсно закони змінюються так часто, що розробник за цим устежити не може. Але чому програміст “кустар-одиночка” або “фірма-кооператив” можуть цю роботу робити? Чому “на місцях “можна впоратися з цим завданням, а” в центрі “немає? Як би часто не змінювалися закони, все одно зміни в програмах потрібно робити!


Якщо фірма розробник декларує “підтримку законодавства”, то все одно змінювати програму вона повинна. Нові клієнти вимагають “свіжу” програму! Все одно розробнику треба відслідковувати законодавство! Так чому користувачеві це “відстеження” повинен робити хтось інший? Де логіка?
І якщо погодиться, що закони змінюються непомірно часто, то, навпаки, з економічних міркувань зміни до програми повинні вноситися централізовано. В іншому випадку споживач повинен укладати договору з “настроювачами” дуже часто! Чим більше змін законів, тим частіше повинен платити замовник? Або як?


* – С.Турчін “Автоматизація управління підприємством … з” коробки “


Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*