В первом выпуске рассылки мы начали обсуждение
вопроса о том, какие выбирать программы
автоматизации учета и управления: 'открытые' или
'закрытые'. Под 'открытыми' программами мы
подразумеваем 'программы-полуфабрикаты', т.е. те,
которые требуют последующей доработки и
содержания программиста для её сопровождения.
'Закрытые' же программы (или 'коробочные'),
напротив, не позволяют пользователю вносить в
себя изменения, но при этом они полностью готовы
к работе - как говорится: 'купил и работай'.
В первом выпуске прозвучало утверждение, что
покупать нужно закрытые коробочные программы.
Почему? Продолжим рассмотрение аргументов в
пользу этого утверждения.
В
конце выпуска обязательно прочтите наш
практический совет.
Открытые или закрытые программы - вот в чем вопрос.
(часть 2)
Открытость
программы лишает пользователя возможности
использовать новые версии программы, которые
выпускает разработчик. Предположим,
разработчик выпустил нужную пользователю открытую
программу. Назовем ее Р-1 (версия 1 от
разработчика). Пользователь изменил ее (именно
для этого предназначена открытость) и
теперь располагает уже другой программой.
Назовем ее П-1 (версия 1 от пользователя).
Прошло время. Изменилось законодательство (или
разработчик исправил ошибку, или просто
доработал) и разработчик выпустил новую версию.
Назовем ее Р-2 (версия 2 от разработчика). В
соответствии с ранее данными обещаниями (при
продаже Р-1) разработчик готов предоставить
свою новую версию всем старым пользователям
(бесплатно или со скидкой). Но что будет делать с
этой новой программой пользователь? Если он
заменит свою программу П-1 на Р-2, то
полностью потеряет все свои наработки (а они ему
нужны)! Если он не заменит П-1 на Р-2, то
ему не будут доступны новые возможности от
разработчика (но и они нужны)! У пользователя есть
только два пути – или с каждой новой версией от
разработчика заново вносить все ранее сделанные
изменения (опять нанимать программистов, а это
затраты, тестирование, ошибки...) или навсегда
отказаться от новых версий, в т.ч. в случаях
изменения законодательства и исправления грубых
ошибок. Другими словами, если пользователь
проглотил наживку и занялся изменением открытой
программы, то новые версии от разработчика
практически ему будут бесполезны. Пользователь
должен будет все сопровождения программы
осуществлять самостоятельно. При этом никто
никого не обманывал. Разработчик предоставил
средства изменения программы, пользователь ими
воспользовался, разработчик предложил новые
версии. В итоге страдает пользователь.
Разработчику только польза – он освободился от
ранее данных обязательств!
При условии
поставки законченного решения открытость
программы остается невостребованной. Все
разработчики декларируют поддержку
законодательства. Но поддержка и полная
поддержка это разные вещи. При реализации полной
поддержки возникает ситуация когда открытость
программы просто не нужна! Разработчики открытых
программ предоставляют пользователю
возможность делать новые документы, новые схемы
проводок и т.п. Предполагается, что пользователь
может захотеть сделать документ, не
предусмотренный законодательством, или сделать
проводку, не предусмотренную законодательством,
или рассчитывать налоги способом, не
предусмотренным законодательством. Я много раз
просил сторонников открытых программ
предоставить мне пример типовой операции
или документа, которые были сделаны
пользователями и при этом противоречили
законодательству. Ни одного примера не получил. И
не надеюсь уже. Суть в том, что открытость
программы нужна не пользователю, а разработчику!
Разработчик пытается (и небезуспешно!)
переложить исправление своих недоделок (т.е.
своего брака!) на плечи пользователя. Кто из
разработчиков 'открытых' программ может сказать,
что его программа (конкретное название!)
реализует [украинское, российское, белорусское]
законодательство полностью?
Причина появления открытых
программ – неспособность разработчика на 100%
реализовать в своих программах поддержку
текущего законодательства и организовать
процесс полного отслеживания его изменений.
Разработчик перекладывает доработку своих
программ на плечи и кошелек пользователя,
называя этот процесс мудреными терминами, как,
например, учет специфики или настройка на
конкретные нужды. Как только пользователь
задаст себе вопрос вроде 'а в чем, собственно,
специфика сделанной по моему заказу (и за мои
деньги) доработки – это же реализация вполне
стандартной и законной хозяйственной схемы...?
' или 'а почему система не поддерживает эту
стандартную и законную схему хозяйствования?',
то сразу рассыпаются все аргументы в пользу открытости
программы.
Часто необходимость открытости
программы обуславливают желанием пользователя
готовить свои отчеты по накопленным данным.
Действительно, нестандартные отчеты
пользователю бывают нужны. Далеко не всегда, но
потребность такая есть. Но для генерации таких
отчетов вовсе не нужно модифицировать и
перенастраивать систему. Достаточно применить
один из большого количества автономных программ
генераторов-отчетов. От разработчика системы
требуется лишь предоставить пользователю
структуру базы данных. Именно так и поступают
фирмы разработчики закрытых программ. Но
далеко не всегда в комплекте открытой
программы есть описание устройства базы данных!
продолжение
следует....
ПРАКТИЧЕСКИЙ СОВЕТ
Представьте: Вы
торгуете чулками-носками. Есть, например, носки
Аль Капоне. Размеры разные. Цвет разный. Но модель
одна. И цена одна. Бухгалтеру и размер, и цвет не
важны! А менеджеру по закупкам - наоборот!
Размеров бывает - 8. Цветов – 10.
Требует ли предлагаемая вам программа
заведения только одной карточки товара на все
эти самые Аль Капоне? И при этом будет ли решать
проблемы учета размера и цвета? Если на каждую
цветовую и размерную модификацию товара
программа требует заведения отдельной карточки,
то при торговле товарами вроде чулков-носков,
кафельной и другой облицовочной плитки,
пластиком и т.п. у вас возникнут неимоверные
сложности. Вы просто утонете в обилии будто бы
разного товара... Не верьте поставщику программы
на слово. Следует своими глазами увидеть такую
работу программы!