26. Возможность контроля плановых запасов.
27. Автоматический учет пеней и штрафов (факт, прогноз и анализ).
28. Учет работы и оплаты менеджеров, торговых агентов, коммивояжеров и др.
29. Слияние/разделение товаров (один товар зарегистрирован в системе с разными кодами, разные товары попали в систему под одним кодом).
30. Слияние/разделение контрагентов (ИНН попадает в систему позже ввода в систему контрагента).
31. Наличие утилит для обрезания и сжатия разбухшей базы данных.
32. Наличие интегрированных в систему средств архивирования данных.
33. И, если честно, все это работает?
* * *
Итак, вы получили ответы на свои вопросы. Что дальше?
Дальше вы, как и предполагалось с самого начала, обнаруживаете, что полностью вам не подходит ни одна из систем.
Теперь сразу же и решительно вычеркните из списка системы, которые точно не годятся, как бы вам ни нравились их интерфейсы, заложенные в них идеи и технологии. Постарайтесь проявить твердость и в общении с начальством по этому поводу. Нужно жестко отсечь системы, использующие СУБД, которые:
– не поддерживают объемы данных, как минимум в десять раз превосходящие объемы, заложенные в проект;
– не поддерживают одновременную работу числа пользователей, превышающего проектное в два-три раза;
– не поддерживают работу в сетях соответствующего масштаба или репликации в распределенной базе, и многое другое, что не лечится, если не было заложено в программное ядро продукта в самом начале его разработки.
Все-таки и интерфейс имеет значение. В системе, в которой при вводе заказа оператор должен при создании каждой новой строки кликнуть на пять кнопок (мышкой) и вручную каждый раз перебрать весь список товаров, точно не подойдет для организации, в которой продавец должен по телефонному звонку набирать заказы на двести строк.
Нужно только определить, для каких рабочих мест интерфейс является критичным, а для каких – нет.
Но не стоит путать удобный интерфейс и графический а-ля Windows – в упомянутом выше случае работа мышкой не всегда лучший вариант. – Д. К.
Вам будет тяжело избежать соблазна самому и уберечь от него своих шефов: системы, которые вы отвергнете, будут иметь самый красивый и удобный интерфейс и как нельзя лучше подходить для решения двух-трех частных задач, о которых именно сейчас думает начальник.
Особо остановлюсь на тестировании объемных и временных характеристик. В этом вопросе не следует доверять ни заверениям разработчиков, ни документации на СУБД. Вы должны проверить это сами. Понятно, что создать тестовую базу в три гигабайта у вас вряд ли получится. Для проверки работоспособности на таких объемах информации вас должны свести с организацией, которая уже использует соответствующую систему и оперирует соответствующими объемами информации. А вот как система работает с документом в тысячи строк (нормальный размер акта инвентаризации магазина), вы должны проверить сами.
