Посмотрите на SugarCRM, Salesforce, Highrise (если компания небольшая), Мегаплан, Битрикс24 (если желаете поддержать отечественного производителя). Просто сравните интерфейсы. Разумеется, в какой-то степени это вкусовщина, но вам это только внедрить, а людям с этим работать целыми днями.
Вторая претензия, это то что системы из обзора мало того что десктопные, они еще и только под Windows. Ок, я могу представить ситуацию когда компания целиком сидит на продуктах MS, но неужели совершенно исключается ситуация когда кто-то когда-нибудь (вы же внедряете CRM не на один год, так?) захочет поработать под OS X, Убунту, или, о ужас, зайти в CRM с мобильно устройства?
По большому счету, мне непонятно почему бы не потратить те же деньги на более гибкий, красивый и перспективный продукт.
Наверное вы и правда молодцы, но из статьи это не очень хорошо понятно. Тут сначала нужно ответить на вопрос: если взять зарплату «небольшого IT-отделу компании из 3 сотрудников» за два года, не проще и быстрее ли было на эти деньги внедрить готовое решение? Судя по описанию, задача была не то что бы какая-то супер-нестандартная.
Да нет, искать надо было в другом столбце, все эти истории с сортировкой для ПОИСКПОЗ тоже актуальны, на сколько я помню (у меня был неотсортированные данные), ну и ПОИСКПОЗ вроде бы тоже находит первый элемент, а мне надо было последний.
На самом деле к ВПР(), а так же практически ко всему что в Экселе связано с поиском или выборками есть масса претензий :)
Я в свое время написал аналог ВПР() за исключением:
— не нужно чтобы значения в столбце поиска были отсортированы.
— ищет только точное совпадение
— возвращает не значение, а номер строки (соответствующая строчка закомментирована)
— возвращает номер строки ПОСЛЕДНЕГО найденного совпадения.
Function VPRL(SearchValue As Variant, Table As Range, SearchColumnNum As Integer, ResultColumnNum As Integer)
Dim i As Integer
For i = 1 To Table.Rows.Count
If Table.Cells(i, SearchColumnNum).Value = SearchValue Then
' VPRL = Table.Cells(i, ResultColumnNum)
VPRL = i
End If
Next i
End Function
То что вы пишете очень интересно. Но не очень понятно почему вы думаете что управленческий учет не умеет обобщать данные? Очевидно что детализировать данные может быть иногда тяжело, но в чем проблема агрегации?
Второе что бросается в глаза, вы так и не назвали прямым текстом самое главное отличие бухгалтерского учета от управленческого — бухгалтерский учет жестко привязан к местному законодательству. Это может показаться мелочью, но на уровне автоматизации это порождает просто тьму сложностей. К тому же бухгалтерский и управленческий учеты развиваются в несколько разных направлениях. Например, сейчас есть такая тенденция что управленческий учет подминает под себя куски hr и управления проектами.
То есть, если честно, вы напоминаете мне людей, занимающихся разработкой автомобиля у когорого в нужный момент выдвигаются крылья и он взлетает. Это все-таки несколко оторванная отреальности, хотя безусловно грандиозная и благородная задача.
Хороший материал, но во-первых нет самого интересного — как были отобраны финалисты?
И во-вторых, почему раз уж в исходном списке для рассмотрения есть такие штуки как Compiere и Adempiere, там нет OpenERP? Из подобных систем она, по-моему, наиболее удачная.
Ну я же тут просто теоретизирую и не предлагаю никому завтра же все это внедрять. И потом я говорю о технической идее, а то что вы пишете это маркетинг в котором я не очень разбираюсь. Не знаю что тут сказать. Да, надо чтоб было понятно для клиента. Разумеется, нужна панель управления.
Поверьте, у авиакомпаний проблемы бывают. Буквально месяц назад был свидетелем того как две пары с детьми не пустили на рейс как раз из-за овербукинга — предложили подождать следующего, который завтра. Естественно я теперь этой авиакомпанией никогда не полечу и всех буду отговаривать.
Да нет, разница есть. Ключевое понятие: ресурсы потребляемые пользователем. Не все потребляют одинаково. Модель Мегаплана конечно гораздо лучше чем у остальных, которые просто продают аккаунты, но все равно (ниже обсуждали) в общем случае получается что нужно покупать столько аккаунтов, сколько всего пользователей, т.к. существует ненулевая вероятность того что все вместе захотят выйти в онлайн.
Кроме того, не обязательно продавать фиксированные ресурсы, можно сделать автоматическое расширение, что бы клиент вообще ни о чем не беспокоился.
Ну там есть дырка под штатив, так что и присоски и все остальное можно прикрутить. Я думаю существенная разница в том, что Кодак конечно не такая защищенная.
Я никому ничего не предлагаю, просто высказываю идею.
Но ведь согласитесь, что на самом деле действительно один отчет «стоит» 10 попугаев, а другой 1000? И в этом смысле система действительно является черным ящиком. И говорить что например 100 попугаев = 1 пользователь это обман.
Вопрос только в том как рассказать об этом клиенту так чтобы он понял сколько попугаев ему нужно. Я не думаю что это невозможно.
Ну так я об этом же говорю, но видимо немного криво :) Модель может быть новая, но она должна быть представлена таким образом, что бы можно было сравнить с чем-то понятным. Это и есть работа маркетологов.
Ну так не нужно продавать несуществующие ресурсы. Я уже писал где-то в другом комменте, что речь идет о системе аналогичной той которой пользуются хостинги, когда продается, грубо говоря, изолированный кусок памяти+диска+процессора. И если клиент все израсходовал — сам себе буратино, но должна быть возможность оперативно докупить.
Не, извините, но я считаю что это ущербный подход. Так реально инновационные вещи никогда бы не продавались, потому что при продаже их нужно было бы сравнивать с чем-то старым, что было бы невозможно, т.к. ничего похожего раньше не было.
При этом я естественно против запугивания потенциально клиента непонятными умными словами и считаю что можно все изложить так чтобы он все понял и даже мог сравнить. Да, для этого может понадобиться некая номинальная умственная деятельность, но если клиент сделать не в состоянии, то может ну его?
Если честно, я предлагаю именно продавать ресурсы + права на использование и некоим образом это не скрывать, потому что это реально и есть то, что продается в SaaS. Только не надо понимать слишком буквально. О том что написано на сайте разработчика в разделе «pricing» должны заботиться маркетологи, это их работа, я говорю только о принципе. Тем не менее я уверен что с помощью простых примеров, понятных среднему менеджеру, процессорное время и память можно конвертировать в пользователей, проекты и все остальное.
Мой опыт меня научил что если положиться на исчезающе малую вероятность какого-либо события, то рано или поздно это событие все-таки произойдет. Мы, например, работаем с серьезными людьми и допускать лажу просто не хочется. К тому же, согласитесь, сложно представить более идиотскую ситуацию, когда придется объяснять заказчику что что-то не сделано вовремя, потому что наши сотрудники не смогли зайти в систему управления проектами.
Я имею ввиду не такой биллинг когда в конце периода выставляется счет в зависимости от использованных ресурсов, а биллинг с, грубо говоря, абонементами. В этом случае прогнозирование ничем не отличается от прогнозирования с обычными тарифами. Даже наверное еще проще, т.к. разработчику всегда точно известно количество проданных ресурсов, за которые он собственно сам платит.