В сентябре были подведены итоги 6-го Международного (страны СНГ) конкурса программного обеспечения в области финансов и бизнеса, в котором приняли участие 56 фирм. Конкурс показал присутствие на рынке широкого спектра программ, что ставит потенциального заказчика перед трудной проблемой выбора. В связи с этим остановлюсь на нескольких, с моей точки зрения, важных аспектах этой проблемы. Надеюсь, что это поможет покупателю совершить меньше ошибок при приобретении необходимого программного продукта. Автор статьи является руководителем проекта по автоматизации магазинов и супермаркетов (программный комплекс "Ветразь", фирма ЛюксСофт). Поэтому излагаемые ниже соображения могут страдать некоторой долей субъективизма, что не дает мне морального права давать сравнительные оценки конкурирующим продуктам. Однако думаю, что читателям будет интересна точка зрения непосредственных разработчиков программного обеспечения, которое получило достаточно широкое распространение на белорусском рынке.

У кого покупать или заказывать разработку программ?

- Ответ однозначен: у надежной фирмы с устоявшейся репутацией. В противном случае слишком велик риск оказаться наедине со своими проблемами, что приведет в итоге к дополнительным крупным косвенным и прямым финансовым затратам. Выбор конкретной фирмы зависит от очень многих объективных и субъективных факторов, и единых рецептов, естественно, здесь не существует. Однако есть принципиальные вопросы, на которые просто необходимо получить четкий ответ.

Знакомство с продуктом

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

1. Помимо ознакомления с продуктом в офисе продавца, должна быть предоставлена возможность его апробации в РЕАЛЬНЫХ условиях заказчика. Программное обеспечение - не тот продукт, который можно оценить по слухам или в момент его показа. Чаще всего требуется определенное время для проверки его РАБОЧЕЙ версии (а не демо-версии) на функциональную полноту применительно к специфике вашего предприятия.

2. Любой программный продукт предъявляет свои требования к вычислительной технике, что в свою очередь определяет финансовые затраты на ее приобретение или модернизацию. Изначально очень важно соотнести свои возможности с предъявляемыми требованиями.

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

4. Несмотря на уверения продавцов программ об их функциональной полноте, особое внимание обратите на следующие моменты:

- гибкость программ относительно изменения политики учета или законодательства;

- организация доступа к информации, ее наглядность, возможность манипуляции выделенными подмножествами информации, трудоемкость пути от "живой" информации к отчету и наоборот и т.д.;

- как поведет себя программа при достижении реальных объемов информации, а не на демонстрационном примере;

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

Обучение, внедрение, сопровождение

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

Оплата за услуги и программное обеспечение

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

Windows или DOS? Клиент-сервер или файл-сервер?

- Любой программист отдаст предпочтение первым альтернативам предлагаемого выбора. И сделает правильно, если будет учтено одно важное соображение: каждая вещь хороша на своем месте. Прошло много времени с момента появления экскаватора, но лопата твердо занимает свое место среди средств производства. Конечно, будущее за новыми технологиями, но в силу складывающихся объективных и субъективных причин предсказывать скорое отмирание DOS-приложений, по меньшей мере, опрометчиво. Когда речь идет о проектировании глобальной информационно-справочной системы или об автоматизации административного контура крупного предприятия, без привлечения клиент-серверной архитектуры вопрос не решить. Но в рамках такого проекта вполне может уживаться и файл-серверные технологии для автоматизации, например, складов или бухгалтерии. Тем более, если они функционально полны по отношению к своим пользователям. Важно, чтобы соответствующие подсистемы могли в регламентном режиме своевременно обмениваться соответствующей информацией. Действительно, наверное, не так важно директору супермаркета знать, на какой минуте продан конкретный товар. Его, как правило, интересует обобщенная информация о торговом процессе, которую должна поддерживать соответствующая подсистема, разработанная уже в клиент-серверной архитектуре. В свою очередь администратор торгового зала не должен знать о финансовом положении магазина и его вполне может устроить добротно сделанная ранее под него разработка. Блочный принцип построения крупных систем позволяет более гибко удовлетворять запросы конкретных пользователей системы и может представлять собой, наверное, не самый худший вариант для автоматизации предприятия. Во всяком случае, на переходный период. Разделение подсистем по данному принципу наверняка позволит сэкономить существенные финансовые средства в силу меньших затрат на ту же вычислительную технику. Именно такой политики придерживается наша фирма. Разработка приложений на новых платформах будет вестись параллельно с развитием и поддержкой уже существующих DOS-приложений. На сегодняшний день большинство фирм переходит на платформу Windows, объявив, что DOS-версии больше не будут иметь дальнейшего развития. По отношению к старым клиентам, мягко говоря, это не всегда справедливо хотя бы по двум соображениям:

1. Сможет ли клиент, если это необходимо, в силу многих причин сменить парк компьютеров?

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

Я буду рад, если приведенные в данной статье соображения помогут вам сделать правильный выбор необходимого для вас программного обеспечения.

Антон КИРКОВСКИЙ