Утверждение: покупать нужно законченные коробочные программы, которые не требуют дополнительной настройки и содержания программиста для её сопровождения.

В многочисленных обзорах "рынка компьютерных программ для автоматизации предприятий" нередко пытаются сопоставить "пути развития" этого рынка на "на Западе" и на пост-советском пространстве. И авторы обзоров практически всегда делают вывод, что пути эти ведут в разные стороны. Изыскания их показывают, что на Западе "... проблему настройки пользователем продукта на свою специфику решили кардинальным образом, – покупатель ищет тот продукт, в котором есть необходимая ему функциональность, вынимает его из коробки, устанавливает и начинает работу".*

Западные программы предельно закрыты и полностью готовы к эксплуатации сразу после покупки. Отечественные же реалии совершенно противоположны - "пользователь может изменить в этих продуктах почти все, т.е. фактически разработать новый. В половине АСУП для этого применяются стандартные языки программирования, в остальных используются собственные средства, что отнюдь не упрощает освоение программ..." *. Другими словами, пользователь, купив такую программу, должен ее доводить до нужного ему уровня. К сожалению, никогда эту тему не развивают, отмечают лишь, что эта сегодняшняя наша особенность "... была характерна для западных АСУП в середине 80-х – на заре появления ПК на рабочих столах большинства бизнес - пользователей" *. Не можем не согласиться с такими утверждениями. И тему эту хотим развить...

Открытость программы полностью снимает ответственность разработчика за ее правильное функционирование. Ни один разработчик никаких претензий за ошибки в работе программы принимать не будет, если программа была изменена пользователем. Если пользователь хоть раз изменит программу (а для этого "открытость" и нужна) – разработчику уже можно не звонить... Пользователь после этого остается со своей системой в полном одиночестве, Многое из того, что разработчик пишет в лицензионном соглашении о своей ответственности, теряет смысл. Мне не известен ни один разработчик, который бы декларировал готовность отвечать за программу, подвергшуюся изменениям со стороны пользователя. При этом, разработчики, расхваливая "открытость" программы, это обстоятельство старательно замалчивают.

Открытость программы лишает пользователя возможности использовать новые версии программы, которые выпускает разработчик. Предположим, разработчик выпустил нужную пользователю открытую программу. Назовем ее Р-1 (версия 1 от разработчика). Пользователь изменил ее (именно для этого предназначена открытость) и теперь располагает уже другой программой. Назовем ее П-1 (версия 1 от пользователя). Прошло время. Изменилось законодательство (или разработчик исправил ошибку, или просто доработал) и разработчик выпустил новую версию. Назовем ее Р-2 (версия 2 от разработчика). В соответствии с ранее данными обещаниями (при продаже Р-1) разработчик готов предоставить свою новую версию всем старым пользователям (бесплатно или со скидкой). Но что будет делать с этой новой программой пользователь? Если он заменит свою программу П-1 на Р-2, то полностью потеряет все свои наработки (а они ему нужны)! Если он не заменит П-1 на Р-2, то ему не будут доступны новые возможности от разработчика (но и они нужны)! У пользователя есть только два пути – или с каждой новой версией от разработчика заново вносить все ранее сделанные изменения (опять нанимать программистов, а это затраты, тестирование, ошибки...) или навсегда отказаться от новых версий, в т.ч. в случаях изменения законодательства и исправления грубых ошибок. Другими словами, если пользователь проглотил наживку и занялся изменением открытой программы, то новые версии от разработчика практически ему будут бесполезны. Пользователь должен будет все сопровождения программы осуществлять самостоятельно. При этом никто никого не обманывал. Разработчик предоставил средства изменения программы, пользователь ими воспользовался, разработчик предложил новые версии. В итоге страдает пользователь. Разработчику только польза – он освободился от ранее данных обязательств!

При условии поставки законченного решения открытость программы остается невостребованной. Все разработчики декларируют поддержку законодательства. Но поддержка и полная поддержка это разные вещи. При реализации полной поддержки возникает ситуация когда открытость программы просто не нужна! Разработчики открытых программ предоставляют пользователю возможность делать новые документы, новые схемы проводок и т.п. Предполагается, что пользователь может захотеть сделать документ, не предусмотренный законодательством, или сделать проводку, не предусмотренную законодательством, или рассчитывать налоги способом, не предусмотренным законодательством. Я много раз просил сторонников открытых программ предоставить мне пример типовой операции или документа, которые были сделаны пользователями и при этом противоречили законодательству. Ни одного примера не получил. И не надеюсь уже. Суть в том, что открытость программы нужна не пользователю, а разработчику! Разработчик пытается (и небезуспешно!) переложить исправление своих недоделок (т.е. своего брака!) на плечи пользователя. Кто из разработчиков "открытых" программ может сказать, что его программа (конкретное название!) реализует [украинское, российское, белорусское] законодательство полностью?

Причина появления открытых программ – неспособность разработчика на 100% реализовать в своих программах поддержку текущего законодательства и организовать процесс полного отслеживания его изменений. Разработчик перекладывает доработку своих программ на плечи и кошелек пользователя, называя этот процесс мудреными терминами, как, например, учет специфики или настройка на конкретные нужды. Как только пользователь задаст себе вопрос вроде "а в чем, собственно, специфика сделанной по моему заказу (и за мои деньги) доработки – это же реализация вполне стандартной и законной хозяйственной схемы...? " или "а почему система не поддерживает эту стандартную и законную схему хозяйствования?", то сразу рассыпаются все аргументы в пользу открытости программы.

Часто необходимость открытости программы обуславливают желанием пользователя готовить свои отчеты по накопленным данным. Действительно, нестандартные отчеты пользователю бывают нужны. Далеко не всегда, но потребность такая есть. Но для генерации таких отчетов вовсе не нужно модифицировать и перенастраивать систему. Достаточно применить один из большого количества автономных программ генераторов-отчетов. От разработчика системы требуется лишь предоставить пользователю структуру базы данных. Именно так и поступают фирмы разработчики закрытых программ. Но далеко не всегда в комплекте открытой программы есть описание устройства базы данных!

Открытая программа это очень дорого для пользователя. Весь смысл открытости заключается в необходимости для пользователя программировать. Эксплуатация "открытой" программы требует от него или содержать своих программистов (а это необходимость платить зарплату), или периодически пользоваться услугами третьих фирм. Причем затраты при этом очень большие. И очень важно то, что, заплатив фирме разработчику за программу, пользователь должен обращаться за услугами к фирмам, которые ему ничем не обязаны. Пользователь платит одним, а за помощью должен обращаться к другим. Разработчику это очень выгодно: деньги получены, а ответственности нет. Выгодно это и настройщику – он ничем пользователю не обязан и поэтому вправе за услугу брать деньги. И берет! И ничто настройщику не мешает отмахнуться от особо надоедливых пользователей. И ничто ему не мешает прекратить отношения с пользователем, у которого возникли серьезные проблемы. Возникает ситуация, когда потребитель вместе с программой не может приобрести ответственность поставщика.

Поставщики "открытых" программ очень не любят попыток выяснения т.н. совокупной стоимости владения их системами. Многочисленные "сравнительные анализы программ", которые часто публикуются в различных изданиях, никогда не анализируют эту стоимость! Причина в том, что разработчик не хочет показывать реальную цену (по причине ее высокого значения) и не может указать заниженное значение – сразу возникают неудобные вопросы... (Как просто в случае закрытых систем: "этот телевизор стоит столько, а этот столько…", "этот текстовый редактор столько, а вот тот чуток больше...")

Открытая программа заставляет пользователя реально покупать не то, что он решил покупать. Пользователю нужны прикладные программы. Все эти скучные "создание накладных", "учет сроков годности товара" и т.п. Но часто он вынужден вместо этого покупать средство программирования, к которому прилагаются в качестве бесплатного "бонуса" типовые прикладные решения. Но пользователю именно этот "бонус" и нужен! А деньги то уплачены за инструмент. И отвечает разработчик за функционирование инструмента, но не прикладных программ. И звонить разработчику (пользоваться бесплатными телефонными консультациями) можно только по вопросам функционирования инструмента. И претензии предъявлять (помните у Райкина: - "...пуговицы хорошо пришиты?...") некому!

Открытая программа порождает юридические проблемы. Ситуация когда платить нужно одному, а ответственность требовать с другого, когда покупаешь одно, а реально получаешь другое, неизбежно порождает правовую неопределенность. Какие гарантии у потребителя? От кого их требовать? Что делать в том или ином случае? Куда звонить, а куда не надо? Все эти вопросы разработчики "закрытых" программ отражают в т.н. "лицензионном соглашении". (Все, кто устанавливал "коробочные программы" сталкивались с текстом и кнопочками "принимаю условия" и "не принимаю условия" – это и есть "лицензионное соглашение". Очень часто находится в коробке и бумажный вариант этого документа.) А что делать разработчикам "открытых" программ? В юридическом документе надо изложить все "как есть" (а "лицензионное соглашение" - это юридический документ). Но все "как есть" разработчик писать не хочет! Зачем открывать глаза пользователю! И остается: или заниматься игрой слов, или, в "особо тяжелых случаях", не предоставлять пользователю лицензионного соглашения вообще! Никто никогда не задумывался, почему поставщик не заключает лицензионного соглашения с потребителем своей продукции? Кто может привести пример западной "коробочной" программы без лицензионного соглашения? Т.е. вообще без лицензионного соглашения! А вот на украинском рынке программ для "автоматизации предприятий" это запросто...

Должен отметить, что чтение "лицензионных соглашений" от разработчиков "открытых программ" может очень позабавить! Особенно, если читать эти документы в режимах "осмысления" и "чтения между строк"... Осмелюсь порекомендовать владельцам (и потенциальным владельцам) "открытых" программ почитать внимательно соответствующие "лицензионные соглашения". Это поучительное занятие...

Да и ситуация, когда разработчик гордо ставит знак защиты авторских прав (copyright) на своей программе и сразу же провоцирует пользователя эту же программу самостоятельно изменять (но "copyright" именно это делать запрещает!), выглядит противоречиво и юридически безграмотно. Или для кого безграмотность, а для кого предусмотрительность? Ведь при малейшем изменении такой программы пользователь автоматически становится нарушителем закона!

Но, что будет, если потребитель покупку будет осуществлять в компании с юристом?

Открытость программы не позволяет быстро реагировать на изменяющееся законодательство. Но часто сторонники открытости утверждают обратное. Рассмотрим, как учитываются изменение законодательства в случае закрытой и открытой программ:

Закрытая программа. Разработчик вынужден отслеживать изменение законодательства уже потому, что он испытывает давление со стороны старых клиентов (им была обещана поддержка при изменении законодательства). Кроме того, ему необходимо иметь актуальную программу (в смысле изменений законов) для новых (потенциальных) клиентов. Зачастую разработчик имеет возможность начать работы по учету изменений еще до официального опубликования закона. Разработчик всегда стремится не потерять время. Пользователь, встав перед фактом необходимости работать по новым инструкциям, вправе требовать от разработчика соответствующей версии. Или версия уже будет готова, или разработчик будет знать, когда она будет готова. В любом случае пользователь может требовать. Требовать, а не просить. И при этом может опираться на ранее данные разработчиком обязательства. Доставить обновленную версию до конечного пользователя очень просто и дешево. Обновление может предоставляться через WWW, по электронной почте, обычной или курьерской почтой, может использоваться дилерская сеть, представительства. Но всегда это прогнозируемая (в смысле временных и денежных затрат) работа.

Открытая программа. Разработчик не отслеживает изменения законов сам. Это должен делать пользователь. Вовремя узнать о готовящихся изменениях. Вовремя поручить работу своим специалистам или договориться о выполнении такой работы с третьей фирмой. Вовремя оттестировать. Вся ответственность на пользователе. Все денежные расходы несет пользователь. Вся организация работ – забота пользователя. И при этом ему никто ничего не обязан. Он проситель. Он заказчик. Он может договориться с настройщиком, но может и не договориться. Пользователь может просто не найти подрядчика, который согласится выполнить работу.

Открытость программы не позволяет качественно вносить модификации в программу при изменении законодательства. Но часто сторонники открытости утверждают обратное. Все изменения, что вносятся в закрытую программу, всегда производятся специалистами фирмы разработчика. Это их работа. Они знают исходные тексты программы, ее архитектуру, особенности. У них есть опыт выполнения такой работы. Это штатные программисты фирмы разработчика. В случае открытой программы картина иная. Изменения часто делают случайные люди, не имеющие соответствующего опыта и возможностей. Да и работа эта часто носит характер халтурки... Неизбежное следствие – качество модификаций закрытой программы несоизмеримо выше качества модификаций открытой программы.

Есть нелогичность и в другом. Предположим, что произошло изменение законодательства. Разработчик закрытой программы производит соответствующие изменения и распространяет новую версию программы. В случае открытой программы на территории страны одновременно производятся одни и те же изменения одной и той же программы, но разными людьми и разными способами. Вся экономическая логика говорит, что такое положение вещей для открытой программы не может обходиться дешевле централизованного изменения для закрытой программы. И лишние затраты неизбежно оплачиваются потребителем.

Открытая программа часто является недоступной. Сама логика открытости подразумевает доступность для пользователя услуг либо своих специалистов, либо специалистов сторонних фирм. В условиях районных центров, сел, поселков, а часто и относительно больших городов, потребитель просто может не найти ни программистов, ни специализированных программистских фирм. Их может вообще не быть в населенном пункте. Или автоматизация нужна только в столице и областных центрах? Для закрытой программы обновление, в худшем случае, можно получить по почте (менее 5 гривен CD-заготовка и 2-3 гривны доставка). Но что делать с открытой программой? Где взять специалиста для доработки?

Да и в условиях большого города у владельцев открытых программ могут быть проблемы. Это касается, в первую очередь, трудных и требовательных пользователей. Многочисленная армия настройщиков может просто сторониться таких клиентов с их огромными базами данных, с очень большим объемом информации или сложным документооборотом. Как быть в этом случае?

В случае открытой программы пользователь зависит от разработчика ничуть не меньше, чем в случае закрытой программы. Сторонники концепции "открытости" программы часто указывают на зависимость пользователя от фирмы разработчика. Мол, перестанет существовать разработчик, и некому будет сопровождать программу. Да. Это так. Но и в случае "открытой" программе нельзя надеяться на "жизнь программы" после "смерти" разработчика. Если платформа перестанет сопровождаться, то долго ли "настройщики" смогут и захотят иметь дело с программой-трупом?

И не надо забывать, что в случае многочисленных изменений "открытой" программы возникает похожая проблема. Пользователь также будет зависеть и от автора "настроек". Практически всегда, когда "настройщик" не справляется с ситуацией и уходит, все работы пользователь должен начинать с новым "настройщиком" заново, предварительно выслушав от него комментарии о некомпетентности предшественника...

Во всяком случае, размер потерь при исчезновении разработчика "закрытой" программы равен ее цене. Кто посчитает размер затрат при эксплуатации "открытой" программы? Все эти многочисленные договора по обслуживанию и "настройке на специфику" и "изменяющееся законодательство"...

Частые изменения законодательства не препятствуют эксплуатации закрытых программ. Нередко целесообразность "особого национального пути" в обсуждаемом вопросе обосновывают якобы частыми изменениями законодательства. Мол, в нашей стране такой поток изменений законов, что наши фирмы-разработчики, в отличие от западных, не могут вовремя делать изменения. Как следствие вывод о необходимости "открытости" программы. У нас есть возражения:

Западные реалии в этом отношении ничуть не лучше наших. Изменения законов там тоже очень часты. Убедиться в этом очень легко, посетив сайты, обслуживающие западные программы. Календарь выхода изменений очень и очень плотный... Но при этом западные фирмы разработчики вполне управляются с задачей отслеживания изменяющегося законодательства. И дело, вероятно, не в законах, а в отношении к делу со стороны разработчиков программ.

Предположим, что действительно законы изменяются так часто, что разработчик за этим уследить не может. Но почему программист "кустарь-одиночка" или "фирма-кооператив" могут эту работу делать? Почему "на местах" можно справиться с этой задачей, а "в центре" нет? Как бы часто не изменялись законы, все равно изменения в программах нужно делать!

Если фирма разработчик декларирует "поддержку законодательства", то все равно изменять программу она должна. Новые клиенты требуют "свежую" программу! Все равно разработчику надо отслеживать законодательство! Так почему пользователю это "отслеживание" должен делать кто-то другой? Где логика?

И если согласится, что законы изменяются непомерно часто, то, наоборот, из экономических соображений изменения в программу должны вноситься централизовано. В противном случае потребитель должен заключать договора с "настройщиками" очень часто! Чем больше изменений законов, тем чаще должен платить заказчик? Или как?

* - С.Турчин "Автоматизация управления предприятием... из "коробки"" "Компьютерное Обозрение" №7 2001 г.