В начале небольшое отступление.
    Представьте себе, что у Вас есть две сотки земли для выращивания картошки и Вам их надо обработать. Вы пойдете в магазин чтобы купить средство для обработки земли. Что Вы купите (вопрос аренды не рассматриваю)? Лопату, мотоблок или трактор? Скорее всего Вы купите лопату, может быть мотоблок, но не трактор. А если у Вас есть гектар земли? То о лопате Вы и не подумаете, а будете покупать трактор. Почему в одном случае Вы выбираете лопату, а в другом - трактор? Какой критерий отбора? В этом примере разные условия: 2 сотки и гектар, т.е. получается, что критерием является - размер обрабатываемой земли? Да, но это критерий, который лежит на поверхности, а основным критерием скорее всего является экономическая целесообразность, так как перед Вами стоит цель - не просто вырастить картошку, но и с наименьшими затратами. Если не важно сколько она будет стоить, то можно и две сотки копать купленным трактором, а гектар - лопатой. А каким будет результат, если сравнивать лопату и трактор отвлеченно от количества обрабатываемой земли? По показателю "производительность" и многим другим лучше окажется трактор, а по показателю "цена" наоборот более предпочтительным будет лопата. Поэтому, все-таки все средства обработки земли надо разбить на группы по объему обрабатываемой земли, который можно обработать данным средством с учетом экономической целесообразности. И сравнивать уже между собой все существующие лопаты и между собой отдельно трактора.
   
    А теперь рассмотрим музейный софт.
    Все специализированное программное обеспечение разработано на основе неких СУБД. Все СУБД исходя из своих возможностей классифицируются по их использованию: для малых предприятий (например, ACCESS); для средних предприятий (например, SQL Server); для крупных предприятий (например, Oracle).
   
    Исходя из возможностей СУБД и программные средства, разработанные на их основе, тоже можно классифицировать по их использованию (применительно к музеям их можно классифицировать в зависимости от количества музейных экспонатов): для малых музеев (например, количество - до 100 000 экспонатов); для средних музеев (например, количество от 100 000 до 1 000 000 экспонатов); для крупных музеев (например, количество от 1 000 000 экспонатов и выше).
   
    Зададим такой же вопрос как и выше. Что будет, если сравнивать (отвлеченно от количества музейных экспонатов) музейный софт, разработанный на ACCESS-е и музейный софт, разработанный на Oracle? По производительности и многим другим показателям лучше будет Oracle, а по цене - ACCESS. Можно конечно использовать для специализированного софта показатель "Цена / производительность", который используется для оценки СУБД, но проблема как и кто его будет рассчитывать.
   
    Мне кажется надо разбить весь специализированный музейный софт на три группы, в зависимости от экономической целесообразности (можно использовать показатель "Цена / среднее количество музейных экспонатов группы музеев" или какой-то другой): для малых, для средних и для крупных музеев.
   
    Внутри каждой группы музейный софт надо оценивать только между собой ("лопаты" с "лопатами", а "трактора" с "тракторами"). По каким показателям? В связи с тем, что мы оцениваем "средства автоматизации учета музейных предметов", то и критерии оценки должны отражать как данный софт позволяет автоматизировать работы по учету (автоматизация ввода и вывода информации в соответствии с Инструкцией по учету и хранению музейных ценностей и др.). Это должно быть главным для оценки специализированного программного обеспечения для автоматизации учета музейных предметов.
   
    Дополнительной группой критериев могут быть критерии, характеризующие дополнительные возможности, предусмотренные в данным программным обеспечением.
   
    Что должен делать АДИТ, если в результате анализа музейного софта получится, что есть очень хороший музейный софт ("трактор") для крупных музеев, а нет хорошего софта ("лопаты") для мелких музеев. Должен ли АДИТ предлагать всем этот "трактор"? Мне кажется нет, и довод, что другого-то нет тут не годится. Какая будет Ваша реакция, когда Вы придете в магазин, что бы приобрести лопату, а Вам будут везде предлагать трактор, говоря что лопат нет? Вы или откажетесь вообще обрабатывать участок, или будете обрабатывать какими-то подручными средствами, но вряд ли будете покупать трактор.
   
    Так и с музейным софтом. Если нет хорошего программного обеспечения для малых и средних музеев, то его надо создать. И задача АДИТ выявить те узкие места в программном обеспечении и дать направление развития специализированного музейного софта фирмам-разработчикам по созданию недостающего музейного софта. Вопрос упирается в деньги. Есть несколько вариантов решения денежной проблемы: 1) получить гранд в одном из Фондов; 2) войти в программу Министерства культуры РФ; 3) привлечь и объединить собственные средства музеев для общей разработки программного обеспечения.
   
    Мне кажется полная "тракторизация" всех музеев не нужна, а нужны хорошие программные средства как для мелких, для средних, так и для крупных музеев.