Продумка 6. Как НЕ нужно выбирать СЭД

Если математическая модель работает негодно, то это не значит, что проблема в целом в математических моделях.

Сделайте больше критериев (но разумное число), укажите веса для каждого критерия (насколько он важен потребителю) укажите уровень реализации критерия. И все будет куда лучше. Откровенно говоря из научных способов это практически единственный - получить требования и по этим требованиям что-то найти. У вас есть научная альтернатива? 

В западном мире эта тема развита больше с методической точки зрения, они легко оперируют всякими Business Requirements Document (Бизнес требования), MRD – Market Requirements Document (Требования рынка), PRD – Product Requirements Document (Требования к продукту), FSD – Functional Specifications Document (Функциональная спецификация) и т.д.

Но для начала хотя бы табличку с функциональными требованиями сделать, уже не плохо. 

Другое дело, что продукт не единственное что надо выбирать. Важны еще люди, устойчивость компании и т.д. 

И еще более другое дело что есть выбор "по ощущениям" и не сказать что он совсем плох. Чаще всего смотрят на людей которые будут внедрять и по их уровню, внешнему виду принимают решение (или как минимум это сильно влияет). У меня был случай когда просто сказали - ведите Генерального, он должен дать слово. Тоже хороший вариант...

+1 к Виктору. 

Требования тоже надо уметь составлять. Возьмем, скажем, пункт "Поддержка беспроводных стандартов Bluetooth". Вы думаете, что он на современном смартфоне сделан лучше или хотя бы также, как на старом? Отлично, возьмите iPhone и передайте файл на Bluetooth на любое устройство (например, на телефон, не являющийся смартфоном). Получилось? Вот то-то же. Значит, требования были некорректно составлены.

Возможно, не совсем в тему, но бывает, когда такие "таблицы" заказчику приносит вендор (продавец, интегратор, оператор). И там в столбцах конкурентов могут оказаться, скажем, не очень коррелирующие с реальной действительностью характеристики. И заказчик может купиться на такое вот "сравнение"...

Просто я видел такой документ от конкурентов :)

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

По-моему такие "простыни" уже уходят в прошлое или остаются простой формальностью.

Причины две: 
1. Лидирующие продукты функционально очень близки (почти каждый из них разрабатывается уже более 10 лет), разница не в наличии функции, а скорее в изящности ее реализации
2. Поставщики, за редким исключением по всем критериям ставят "+", т.к. большинство требований описаны таким языком, что понять, что же под этим подразумевалось - можно все, что угодно (или так как тебе больше нравится :)). 
Пример банального, на первый взгляд, требования: "Возможность гибкого распределения прав доступа к объектам системы" - у всех "+", у ВСЕХ, но за этим требованием стоит "целый мир" и мы то с вами знаем, где это действительно гибко и мощно, а где "слабое подобие...". 
Или "Интуитивно понятный интерфейс" - у всех "+", всегда, по-другому и быть не может, и как этот плюс оценить не видя продукт, не поработав с ним лично хотя бы пару часов?

Вывод: на первый план выходят совсем другие критерии. Я не говорю, что технические аспекты не важны, еще как важны, но для Заказчика при выборе продукта это третий, а может и четвертый параметр.

Согласен с Александром, количественное сравнение не имеет уже большого смысла - потому что "на бумаге" у всех везде "+", а качественное сравнение каким-то методом - еще бОльший субъективизм (припоминаю как "гении СЭД" со стороны Заказчика ставили за какую-то функцию одному продукту 7 баллов, а другому 8 баллов, КАК ВЫ ЭТО СМОГЛИ, ГДЕ ВАС ЭТОМУ НАУЧИЛИ? :))

Лучший вариант для Заказчика, с моей точки зрения: в требованиях описывается некий кейс (задача), и все заинтересованные поставщики на демонстрации показывают решение этой задачи, причем на реальных объемах Заказчика (генерировать N тысяч документов не должно быть проблемой). Тут 80-90% требований (действительно востребованных) всплывет сама собой и будет наглядно продемонстрирована. Как оценивать? Как в КВН (впечатлило что-то ставим "+"), или как в хоккее по системе "Плюс/Минус" - не важно, главное, что это не математическое сложение плюсов, которые поставщики сами же себе и нарисовали :) 

И не будет таких провалов: все супер, по всем функциональным параметрам 10 баллов, продукт "математически" выигрывает, правда при 10 пользователях "колом встает"...но за этот параметр у него свои 2 балла - честно отразили :)

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

Могу лишь добавить, что развёрнутые комментарии к пунктам перечня, как вы правильно сказали, тем эффективнее, чем более опытный продавец их готовит. Добавьте в свою таблицу пункт «Чтоб телефон жил долго на одном заряде батареи», и вы получите цифры с тьмой звёздочек. Как победить звёздочки? Выставлять более конкретные требования. Как их детализировать, если никто в компании, готовящей почву для новой системы, не знает нюансов? Это уже за пределами текущего обсуждения (хотя и интересная тема).

Не в тему, просто поворчу... Что заставляет писать слово "заказчик" с большой буквы? Не термин, не имя собственное вроде как. Плохо, что мы даже в тексте ведем себя излишне подобострастно. 

Вот тут совсем уже... с одной стороны сильные сомнения в умственных способностях, но все таки Заказчик )). 

Заказчик - ровно потому же, почему и Система, Генеральный директор...Почитайте http://doc-style.ru/SPR/?id=1.4 и возвращаемся к теме :)

Прочитал. Не увидел ничего, что бы позволило в данном случае использовать слово "заказчик" с заглавной буквы.

И я бы, конечно, рекомендовал использовать официальные правила русского языка: http://www.gramota.ru/spravka/rules/?rub=prop. 

Не поленился, нашел ответ на грамоте.ру: http://www.gramota.ru/spravka/buro/29_337810

Прошу дать разъяснение на предмет применения заглавных букв в таких словах как: Договор, Исполнитель, Стороны, Заказчик, при оформлении деловой документации (договор и.т.п.). Насколько видно из практики эти слова приобрели значение имён собственных. Правильно-ли это?
saruff

Ответ справочной службы русского языка

С прописной буквы пишутся слова, "замещающие" собой в тексте документа неоднословные термины: заказчик работ и услуг фирма такая-то (далее Заказчик) и т. п.

Но я почти сдался, кстати. Раньше у меня был список слов, которые при обнаружении в документе приводят к отказу в согласовании. Недавно я его отменил. Там было, например: 

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

Число - это абстрактная сущность, используемая для описания количества. А вот цифры — знаки для записи чисел. Нет цифры 125! 

Озвучить, -чу, -чишь; -ченный; сов., что (спец.). Записать звуковое сопровождение (фильма) отдельно от съёмки. Клиент не может озвучить требование! Может Симпсонов озвучить, это максимум.

Скоро, видимо, и "Заказчика" приму (.

Вспомнила, что был у нас на сайте пост про замечательный сервис сравнения ECM-систем западный. Решила посмотреть, какие там были критерии. Вот он этот пост Сервис для выбора ECM-системы. Но(!) сервис не работает, отутствует как факт, вместе с компанией. История умалчивает, что случалось. Надеюсь, это не все 194 вендора, которые были в их базе, наслали проклятия на них. Видимо тяжела ноша сравнения, не вынесли. :)

Осталась только ECM Maturity Model http://mike2.openmethodology.org  Вот так...

Добавь сюда так и не опубликованный отчет DSS Consulting, которая (если судить по сайту) тоже дышит на ладан... И получится, что сравнение систем как таковое никому особо (я имею ввиду клиентов - не вендоров) и не нужно.

Все верно, вопрос очень не простой, и сто раз приходится писать что оценки IMHO, что это часто вопрос вкусов, но тем не менее вопрос актуальный, он остается и клиенты его задают. Для меня зачастую вопрос схож с "Какой авто лучше, AUDI или BMW?", ммм...кому  как...можно высказать личное предпочтение, но от этого другой не становится плохим :)

Я продолжу линию защиты оценки по требованиям ). Хотя и не утверждаю, что она грамотно применяется у нас.

Для потребительских товаров, авторынка в частности, важнейшим критерием является восприятие бренда. Для обычного человека это формулируется "нравится или нет". Но там тоже масса критериев - приверженность определенным ценностям, отнесение к конкретной страте и т.д. Например, добавьте критерий: "Положительное восприятие средним классом г. Москвы как машины для успешных, молодых бизнесменов". И победит известно кто. А второй как раз будет хуже.

Что касается СЭД, то тут проще. Нет потребности оценивать личные предпочтения - важны только бизнес цели.

DSS не сравнивал по критериям. Есть множество табличек сравнивающих теплое с мягким. Западный пример, казалось, говорил "Счастье возможно - это просто вы не доросли". Но в реальности я ставлю "+" подходу Вячеслава Лазарева.

Не скажу про "Audi vs. BMW", но если вернуться к телефонам, то там-то как раз всегда есть объективные аргументы в ту или иную сторону. Другое дело, что если именно они для покупателя не важны, то начинается вкусовщина.