Открытые или закрытые программы -
вот в чем вопрос
Олег Сиголов (сторонник "закрытых" систем)
Илья Коптилин (сторонник "открытых" систем),
технический директор ОАО "Программные Системы"
Илья Коптилин (сторонник "открытых" систем),
технический директор ОАО "Программные Системы"
Рано или поздно предприятия встают перед необходимостью приобретения программных комплексов, автоматизирующих различные аспекты их хозяйственной деятельности. Какую систему выбрать: готовое "коробочное" решение или открытый для доработок прототип? Данная статья представляет собой заочный диалог двух специалистов, отстаивающих противоположные точки зрения. Истина, возможно, где-то посередине.
Что есть "открытость"?
И.К.: "Открытые" программы - это системы, разработанные таким образом, чтобы обеспечивать свою модификацию и дополнение в процессе эксплуатации, а также возможность работы с другими программными продуктами. Я предлагаю сразу говорить не о программах, а о программных системах, т. е. комплексах программного обеспечения для работы с технологическим оборудованием (производственная автоматика, весы, сканеры, кассы и т. д.), базами данных, пользовательским интерфейсом и принятыми на предприятии процедурами учета, планирования и контроля (бизнес-логика). Такой подход позволит понять предпосылки появления "открытых" программных систем.О.С.: В многочисленных обзорах "рынка компьютерных программ для автоматизации предприятий" нередко пытаются сопоставить "пути развития" этого рынка "на Западе" и на постсоветском пространстве. И авторы обзоров практически всегда делают вывод, что пути эти ведут в разные стороны. Изыскания их показывают, что на Западе "... проблему настройки пользователем продукта на свою специфику решили кардинальным образом, - покупатель ищет тот продукт, в котором есть необходимая ему функциональность, вынимает его из коробки, устанавливает и начинает работу"љ*. Западные программы предельно закрыты и полностью готовы к эксплуатации сразу после покупки. Отечественные же реалии совершенно противоположны: "Пользователь может изменить в этих продуктах почти все, т. е. фактически разработать новый. В половине АСУП для этого применяются стандартные языки программирования, в остальных используются собственные средства, что отнюдь не упрощает освоение программ..."*. Другими словами, пользователь, купив такую программу, должен ее доводить до нужного ему уровня. К сожалению, никогда эту тему не развивают, отмечают лишь, что эта сегодняшняя наша особенность "... была характерна для западных АСУП в середине 80-х - на заре появления ПК на рабочих столах большинства бизнеспользователей"*. Не можем не согласиться с такими утверждениями. И тему эту хотим развить...
"Открытость": оно вам надо?љ
О.С.: При условии поставки законченного решения "открытость" программы остается невостребованной. Все разработчики декларируют поддержку законодательства. Но поддержка и полная поддержка - это разные вещи. При реализации полной поддержки возникает ситуация, когда "открытость" программы просто не нужна! Разработчики "открытых" программ предоставляют пользователю возможность делать новые документы, новые схемы проводок и т. п. Предполагается, что пользователь может захотеть сделать документ, не предусмотренный законодательством, или сделать проводку, не предусмотренную законодательством, или рассчитывать налоги способом, не предусмотренным законодательством. Я много раз просил сторонников "открытых" программ предоставить мне пример типовой операции или документа, которые были сделаны пользователями и при этом противоречили законодательству. Ни одного примера не получил. И не надеюсь уже. Суть в том, что "открытость" программы нужна не пользователю, а разработчику! Разработчик пытается (и небезуспешно!) переложить исправление своих недоделок (т. е. своего брака!) на плечи пользователя. Кто из разработчиков "открытых" программ может сказать, что его программа (конкретное название!) реализует законодательство (украинское, российское, белорусское) полностью?Причина появления "открытых" программ - неспособность разработчика на 100% реализовать в своих программах поддержку текущего законодательства и организовать процесс полного отслеживания его изменений. Разработчик перекладывает доработку своих программ на плечи и кошелек пользователя, называя этот процесс мудреными терминами, как, например, "учет специфики" или "настройка на конкретные нужды". Как только пользователь задаст себе вопрос вроде "а в чем, собственно, специфика сделанной по моему заказу (и за мои деньги) доработки - это же реализация вполне стандартной и законной хозяйственной схемы?" или "а почему система не поддерживает эту стандартную и законную схему хозяйствования?", то сразу рассыпаются все аргументы в пользу "открытости" программы.
Часто необходимость "открытости" программы обуславливают желанием пользователя готовить свои отчеты по накопленным данным. Действительно, нестандартные отчеты пользователю бывают нужны. Далеко не всегда, но потребность такая есть. Но для генерации таких отчетов вовсе не нужно модифицировать и перенастраивать систему. Достаточно применить один из большого количества автономных программ генераторов-отчетов. От разработчика системы требуется лишь предоставить пользователю структуру базы данных. Именно так и поступают фирмы-разработчики "закрытых" программ. Но далеко не всегда в комплекте "открытой" программы есть описание устройства базы данных!
"Открытость" программы лишает пользователя возможности использовать новые версии программы, которые выпускает разработчик. Предположим, разработчик выпустил нужную пользователю открытую программу. Назовем ее Р-1 (версия 1 от разработчика). Пользователь изменил ее (именно для этого предназначена "открытость") и теперь располагает уже другой программой. Назовем ее П-1 (версия 1 от пользователя). Прошло время. Изменилось законодательство (или разработчик исправил ошибку, или просто доработал), и разработчик выпустил новую версию. Назовем ее Р-2 (версия 2 от разработчика). В соответствии с ранее данными обещаниями (при продаже Р-1) разработчик готов предоставить свою новую версию всем старым пользователям (бесплатно или со скидкой). Но что будет делать с этой новой программой пользователь? Если он заменит свою программу П-1 на Р-2, то полностью потеряет все свои наработки (а они ему нужны)! Если он не заменит П-1 на Р-2, то ему не будут доступны новые возможности от разработчика (но и они нужны)! У пользователя есть только два пути: или с каждой новой версией от разработчика заново вносить все ранее сделанные изменения (опять нанимать программистов, а это затраты, тестирование, ошибки...), или навсегда отказаться от новых версий, в т. ч. в случаях изменения законодательства и исправления грубых ошибок. Другими словами, если пользователь проглотил наживку и занялся изменением "открытой" программы, то новые версии от разработчика практически ему будут бесполезны. Пользователь должен будет все сопровождения программы осуществлять самостоятельно. При этом никто никого не обманывал. Разработчик предоставил средства изменения программы, пользователь ими воспользовался, разработчик предложил новые версии. В итоге страдает пользователь. Разработчику только польза - он освободился от ранее данных обязательств!
В случае "открытой" программы пользователь зависит от разработчика ничуть не меньше, чем в случае "закрытой" программы. Сторонники концепции "открытости" программы часто указывают на зависимость пользователя от фирмы-разработчика. Мол, перестанет существовать разработчик, и некому будет сопровождать программу. Да. Это так. Но и в случае "открытой" программы нельзя надеяться на ее "жизнь" после "смерти" разработчика. Если платформа перестанет сопровождаться, то долго ли "настройщики" смогут и захотят иметь дело с программой-трупом?
И не надо забывать, что в случае многочисленных изменений "открытой" программы возникает похожая проблема. Пользователь также будет зависеть и от автора "настроек". Практически всегда, когда "настройщик" не справляется с ситуацией и уходит, все работы пользователь должен начинать с новым "настройщиком" заново, предварительно выслушав от него комментарии о некомпетентности предшественника...
Во всяком случае, размер потерь при исчезновении разработчика "закрытой" программы равен ее цене. Кто посчитает размер затрат при эксплуатации "открытой" программы? Все эти многочисленные договора по обслуживанию и "настройке на специфику" и "изменяющееся законодательство"...
љ
И.К.: В условиях рынка основным движущим мотивом приобретения программных систем является стремление получить конкурентное преимущество. Если бы все ограничивалось тривиальным желанием избавиться от рутины! Возможно, это особенности национального управления, но я не встретил ни одного руководителя, который бы не сказал: "К нам нужен особый подход. Мы решаем специфичные задачи". И в той или иной мере это всегда правда. Дело в том, что нельзя втиснуть все виды хозяйственной деятельности в рамки - будь то законодательные или программные. Развитие бизнеса, как правило, значительно опережает нормативную стандартизацию, ведь разрешено все, что явным образом не запрещено. В этом случае прибегают к комбинации стандартов де-юре (официально принятых) и де-факто (возникающих на лету). Разработчики программного обеспечения вынуждены распределять свои разработки по разным уровням: относительно стабильной технологической платформы и прикладных решений, легко изменяемых и оперирующих понятиями, близкими к предметной области конкретного бизнес-приложения. Таким образом, предпосылкой появления "открытых" систем является не попытка полностью реализовать законодательство (это невозможно), но стремление разговаривать с бизнесом на языке бизнеса. И процесс этот будет продолжаться. Уже сейчас появляются системы - полноценные "корпоративные конструкторы", такие как Abacus Financial. Это уже не просто набор баз данных, а скорее, система управления знаниями. При соответствующей подготовке пользователи могут сами вносить изменения в логику функционирования системы, не ограничиваясь предложенным шаблоном и не погружаясь в дебри программирования. Централизованное обновление логики происходит почти так же естественно, как и обучение специалиста на курсах. Но даже в таких современных системах, где бизнес-правила непосредственно выражаются в низкоуровневых процедурах манипуляции с базами данных и интерфейсом (1С:Предприятие) предусмотрены мощные средства обновления информационных баз, с возможностью версионного контроля (отслеживание прямых "потомков" и "предков" конкретной конфигурации) и пообЪектного принятия изменений.
Возможность такого доступа и изменения базы данных позволяет решать многие задачи привычными для пользователя инструментами, использовавшимися до приобретения системы. Более того, наличие встроенных инструментов снижает затраты на приобретение внешних специализированных модулей (например, для построения отчетов по базе данных) и гарантирует максимально эффективное, с точки зрения программирования, использование системы.
Создание "открытой" системы снижает затраты разработчика на текущее сопровождение пользователей, освобождая его для решения концептуальных задач, поднимающих продукт на новый уровень. Действительно, в любом случае нужно позволять пользователю что-то модифицировать, хоть размер шрифта. Но подслеповатому бухгалтеру могут понадобиться горизонтальные линии между строк отчета. Будет ли корпорация, выпускающая "закрытую" ВСЕ УЧИТЫВАЮЩУЮ ПРОГРАММУ, настраивать отчеты для этого клиента? Очевидно, она выпустит релиз с новой опцией - "горизонтальная полоса". Конечно, по такому пустяку можно не торопиться - ведь речь идет о выходе НОВОГО РЕЛИЗА ВСЕ УЧИТЫВАЮЩЕЙ ПРОГРАММЫ с тысячами новых опций. А как насчет вертикальных полос?
"Закрытая" система (программная в том числе) изначально менее жизнеспособна, чем открытая. Даже в древние времена жен брали из других племен. Дело в том, что в небольшом коллективе разработчиков более вероятны стагнационные процессы, болезни развиваются быстрее и лечатся труднее - ввиду малых ресурсов, дефицита инициативы и других организационных факторов. Таким образом, чем больше социальная группа, вовлеченная в разработку и поддержание программного продукта, тем больше потенциал его развития.
"Открытый" и "закрытый" способы
выворачивания карманов
О.С.: "Открытая" программа - это очень дорого для пользователя. Весь смысл "открытости" заключается в необходимости для пользователя программировать. Эксплуатация "открытой" программы требует от него или содержать своих программистов (а это необходимость платить зарплату), или периодически пользоваться услугами третьих фирм. Причем затраты при этом очень большие. И очень важно то, что, заплатив фирме-разработчику за программу, пользователь должен обращаться за услугами к фирмам, которые ему ничем не обязаны. Пользователь платит одним, а за помощью должен обращаться к другим. Разработчику это очень выгодно: деньги получены, а ответственности нет. Выгодно это и настройщику: он ничем пользователю не обязан и поэтому вправе за услугу брать деньги. И берет! И ничто настройщику не мешает отмахнуться от особо надоедливых пользователей. И ничто ему не мешает прекратить отношения с пользователем, у которого возникли серьезные проблемы. Возникает ситуация, когда потребитель вместе с программой не может приобрести ответственность поставщика.Поставщики "открытых" программ очень не любят попыток выяснения т. н. совокупной стоимости владения их системами. Многочисленные "сравнительные анализы программ", которые часто публикуются в различных изданиях, никогда не анализируют эту стоимость! Причина в том, что разработчик не хочет показывать реальную цену (по причине ее высокого значения) и не может указать заниженное значение - сразу возникают неудобные вопросы... (Как просто в случае "закрытых" систем: "этот телевизор стоит столько, а этот столько..", "этот текстовый редактор столько, а вот тот чуток больше...".)
"Открытая" программа заставляет пользователя реально покупать не то, что он решил покупать. Пользователю нужны прикладные программы. Все эти скучные "создание накладных", "учет сроков годности товара" и т. п. Но часто он вынужден вместо этого покупать средство программирования, к которому прилагаются в качестве бесплатного "бонуса" типовые прикладные решения. Но пользователю именно этот "бонус" и нужен! А деньги-то уплачены за инструмент. И отвечает разработчик за функционирование инструмента, но не прикладных программ. И звонить разработчику (пользоваться бесплатными телефонными консультациями) можно только по вопросам функционирования инструмента. И претензии предЪявлять (помните у Райкина - "...пуговицы хорошо пришиты?..") некому!
Есть нелогичность и в другом. Предположим, что произошло изменение законодательства. Разработчик "закрытой" программы производит соответствующие изменения и распространяет новую версию программы. В случае "открытой" программы на территории страны одновременно производятся одни и те же изменения одной и той же программы, но разными людьми и разными способами. Вся экономическая логика говорит, что такое положение вещей для "открытой" программы не может обходиться дешевле централизованного изменения для "закрытой" программы. И лишние затраты неизбежно оплачиваются потребителем.
љ
И.К.: Компания, встающая на путь информационных преобразований, должна отчетливо представлять, что затраты на ИТ отныне станут постоянной долей ее бюджета. Не получится ограничиться покупкой "коробки" - потребуются затраты на обучение персонала, изменение технологии учета и управления. Чтобы получить реальную отдачу от информатизации, необходимо привлечение специалистов. Самым оптимальным вариантом является создание собственной службы информационных технологий: программное обеспечение - это тоже имущество, а у каждого имущества должен быть конкретный хозяин. Естественно, чем более открытая система, тем больше информационных потребностей вы сможете удовлетворить и тем эффективнее сможете использовать уже имеющиеся наработки.
Если говорить об общеэкономической выгоде, то разработчик "закрытой" системы является, по сути, монополистом, и не обязательно естественным: обладая спецификациями, многие компании могут провести некоторые работы лучше, чем сам разработчик. Примером тому могут служить внедренческие центры, поставляющие готовые решения на платформе 1С:Предприятие. Такого рода монополия не может быть экономически и технологически выгодной.
Юридические нюансы
О.С.: "Открытость" программы полностью снимает ответственность разработчика за ее правильное функционирование. Ни один разработчик никаких претензий за ошибки в работе программы принимать не будет, если программа была изменена пользователем. Если пользователь хоть раз изменит программу (а для этого "открытость" и нужна) - разработчику уже можно не звонить... Пользователь после этого остается со своей системой в полном одиночестве. Многое из того, что разработчик пишет в лицензионном соглашении о своей ответственности, теряет смысл. Мне неизвестен ни один разработчик, который бы декларировал готовность отвечать за программу, подвергшуюся изменениям со стороны пользователя. При этом разработчики, расхваливая "открытость" программы, это обстоятельство старательно замалчивают."Открытая" программа порождает юридические проблемы. Ситуация, когда платить нужно одному, а ответственность требовать с другого, когда покупаешь одно, а реально получаешь другое, неизбежно порождает правовую неопределенность. Какие гарантии у потребителя? От кого их требовать? Что делать в том или ином случае? Куда звонить, а куда не надо? Все эти вопросы разработчики "закрытых" программ отражают в т. н. "лицензионном соглашении". (Все, кто устанавливал "коробочные программы", сталкивались с текстом и кнопочками "принимаю условия" и "не принимаю условия" - это и есть "лицензионное соглашение". Очень часто находится в коробке и бумажный вариант этого документа.) А что делать разработчикам "открытых" программ? В юридическом документе надо изложить все "как есть" (а "лицензионное соглашение" - это юридический документ). Но все "как есть" разработчик писать не хочет! Зачем открывать глаза пользователю! И остается или заниматься игрой слов, или, в "особо тяжелых случаях", не предоставлять пользователю лицензионного соглашения вообще! Никто никогда не задумывался, почему поставщик не заключает лицензионного соглашения с потребителем своей продукции? Кто может привести пример западной "коробочной" программы без лицензионного соглашения? Т. е. вообще без лицензионного соглашения! А вот на украинском рынке программ для "автоматизации предприятий" это запросто...
Должен отметить, что чтение "лицензионных соглашений" от разработчиков "открытых" программ может очень позабавить! Особенно, если читать эти документы в режимах "осмысления" и "чтения между строк"... Осмелюсь порекомендовать владельцам (и потенциальным владельцам) "открытых" программ почитать внимательно соответствующие "лицензионные соглашения". Это поучительное занятие.
Да и ситуация, когда разработчик гордо ставит знак защиты авторских прав (copyright) на своей программе и сразу же провоцирует пользователя эту же программу самостоятельно изменять (но "copyright" именно это делать запрещает!), выглядит противоречиво и юридически безграмотно. Или для кого безграмотность, а для кого предусмотрительность? Ведь при малейшем изменении такой программы пользователь автоматически становится нарушителем закона!
Но что будет, если потребитель покупку будет осуществлять в компании с юристом?
љ
И.К.: Большой и несомненный плюс "открытых" систем - это свобода выбора. В состав поставки всегда входит базовый набор настроек для ведения хозяйственной деятельности. Дальше открывается простор для деятельности. Конечно, слабая регламентация этой деятельности налицо, и страдают от этого как пользователи, так и поставщики. Основной проблемой является разделение авторских прав на платформу и настройку и защита этих прав. На данный момент настройки являются действительно чуть ли не бесплатным приложением, а об аппаратной защите и речи не идет. А бесплатный
товар - это несерьезно. Не нужно обращаться с пользователем, как с несмышленым ребенком - в лицензионном договоре ("соглашении" на западный манер) могут быть прописаны его права по изменению настроек и степень собственной ответственности за определенные модификации. Не нужно также забывать, что в данном случае действует также ГК в части договора купли-продажи и ФЗ "Об авторском и смежном праве". Многое находится и в руках покупателей - требуйте от внедренцев гарантий, четких договоров, умейте оценивать и отсеивать недобросовестных продавцов, дорожите своими деньгами и временем.
Окончание в следующем номере
 |
љ*С. Турчин "Автоматизация управления предприятием... из "коробки"". "Компьютерное Обозрение" N7 2001 г.
|
Практический совет
Представьте: вы торгуете кефиром. У кефира ограниченный срок годности. Вот купили вы одну партию кефира, а потом еще и еще...ћ Отслеживает программа все эти партии или сваливает весь кефир в кучу?
ћ Всегда ли вы можете знать, сколько у вас кефира "свежего надолго", а сколько "свежего на один день"?
ћ Сможете ли вы на этот разный кефир установить разную цену?
Пусть вам покажут все партии кефира, раздельно существующие в памяти компьютера. Это очень важно! Если таких свойств у программы нет, то о работе с товарами, имеющими ограниченный срок хранения, не может быть и речи! Не доверяйте разработчику (продавцу) программы. Вы должны своими глазами увидеть раздельные партии товара!
|
Практический совет
Представьте: вы торгуете чулками-носками. Есть, например, носки Аль Капоне. Размеры разные. Цвет разный. Но модель одна. И цена одна. Бухгалтеру и размер, и цвет не важны! А менеджеру по закупкам - наоборот! Размеров бывает 8. Цветов - 10. Требует ли предлагаемая вам программа заведения только одной карточки товара на все эти самые Аль Капоне? И при этом будет ли решать проблемы учета размера и цвета? Если на каждую цветовую и размерную модификацию товара программа требует заведения отдельной карточки, то при торговле товарами вроде чулков-носков, кафельной плитки, пластиком и т. п. у вас возникнут неимоверные сложности. Вы просто утонете в обилии будто бы разного товара... Не верьте поставщику программы на слово. Следует своими глазами увидеть такую работу программы! |
Практический совет
Тест из разряда анекдотичных!Из-за некоторых особенностей законодательства (в Украине, например), многие программы будут "сыпаться" от такого теста! Назовем этот тест "украинским"! (Но и россиянам расслабляться не следует! Лучше проверить!)
Представьте: вы торгуете краской. У вас есть хорошая краска. Стоит одна банка 20 гривен (рублей) с налогом на добавленную стоимость. К вам приходит покупатель и просит выписать счет на 20 банок по 20 гривен с НДС!
Пусть поставщик программы создаст счет. При вашем непосредственном участии! Сумма счета с ндс должна быть 400! Ни копейкой больше, ни копейкой меньше! Двадцать умножить на двадцать - должно быть четыреста! Наши исследования показали разброс от 3 до 62(!) копеек!
Уверяем, вас сильно позабавят пояснения разработчика!
Комментарии
7а правда, С1 - это че -открытая система, те канструктор ? по-моиму вроди как канструктор. А про исходный код - это дилетантская чушь.
Непонятно конечно к чему последние три совета, скорее всего для "закрытых систем".
А по мне лучше "открытая",чем "закрытая" потому, что все движется и все развивается, а насчет цены "открытой" системы - это и вправду сложный вопрос. По крайней мере для меня, как для программиста!