playground

Так ведь эти согловские релюшки работают как ВЫключатель, а у вас ПЕРЕключатель.

А что за реле вы использовали?
Судя по схеме, оно работает как переключатель.

людям хочется работать в стабильной программе, не завися от скорости Интернета, отклика облачного сервера и т.д…

Вы правда считаете что, например, RegionSoft CRM на Firebird более стабильна чем SugarCRM с 1,5М пользователей и огромным комьюнити разработчиков?

Насчет устройств и операционных систем — некоторые из них можно спокойно поднять под Wine.

Зачем? :)

А насчет мобильного — ну не представляю я, как можно работать в CRM (именно работать, не просматривать) с маленького или даже лопатистого девайса.

Очень часто нужно именно что «просмотреть», а работать с веб-интерфейсом на планшете можно вполне полноценно.

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

Вы серьезно думаете что десктопные системы более перспективны (и будут дольше поддерживаться) чем веб?

Посмотрите на SugarCRM, Salesforce, Highrise (если компания небольшая), Мегаплан, Битрикс24 (если желаете поддержать отечественного производителя). Просто сравните интерфейсы. Разумеется, в какой-то степени это вкусовщина, но вам это только внедрить, а людям с этим работать целыми днями.
Вторая претензия, это то что системы из обзора мало того что десктопные, они еще и только под Windows. Ок, я могу представить ситуацию когда компания целиком сидит на продуктах MS, но неужели совершенно исключается ситуация когда кто-то когда-нибудь (вы же внедряете CRM не на один год, так?) захочет поработать под OS X, Убунту, или, о ужас, зайти в CRM с мобильно устройства?
По большому счету, мне непонятно почему бы не потратить те же деньги на более гибкий, красивый и перспективный продукт.

Да, на фоне действительно современных систем, все что приведено в обзоре выглядит диковато.

Судя по блок-схеме, Jira не интегрирована ни с Jenkins, ни с GIT?

Всю жизнь думал что «накерниться» это от слова керн.

Наверное вы и правда молодцы, но из статьи это не очень хорошо понятно. Тут сначала нужно ответить на вопрос: если взять зарплату «небольшого 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? Из подобных систем она, по-моему, наиболее удачная.

Надеюсь что кто-нибудь все-таки реализует это быстрее и это станет его конкурентным преимуществом :)

Ну я же тут просто теоретизирую и не предлагаю никому завтра же все это внедрять. И потом я говорю о технической идее, а то что вы пишете это маркетинг в котором я не очень разбираюсь. Не знаю что тут сказать. Да, надо чтоб было понятно для клиента. Разумеется, нужна панель управления.

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

Да нет, разница есть. Ключевое понятие: ресурсы потребляемые пользователем. Не все потребляют одинаково. Модель Мегаплана конечно гораздо лучше чем у остальных, которые просто продают аккаунты, но все равно (ниже обсуждали) в общем случае получается что нужно покупать столько аккаунтов, сколько всего пользователей, т.к. существует ненулевая вероятность того что все вместе захотят выйти в онлайн.

Кроме того, не обязательно продавать фиксированные ресурсы, можно сделать автоматическое расширение, что бы клиент вообще ни о чем не беспокоился.

Ну там есть дырка под штатив, так что и присоски и все остальное можно прикрутить. Я думаю существенная разница в том, что Кодак конечно не такая защищенная.

Посмотрите Kodak Playsport.

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

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

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

Да, такая у 37signals философия, но это не значит что все остальные должны ей следовать.

Я никому ничего не предлагаю, просто высказываю идею.
Но ведь согласитесь, что на самом деле действительно один отчет «стоит» 10 попугаев, а другой 1000? И в этом смысле система действительно является черным ящиком. И говорить что например 100 попугаев = 1 пользователь это обман.
Вопрос только в том как рассказать об этом клиенту так чтобы он понял сколько попугаев ему нужно. Я не думаю что это невозможно.

Ну так я об этом же говорю, но видимо немного криво :) Модель может быть новая, но она должна быть представлена таким образом, что бы можно было сравнить с чем-то понятным. Это и есть работа маркетологов.

Так там тот же вопрос по сути, но тут человек более развернуто изложил. Или нет?

Ну так не нужно продавать несуществующие ресурсы. Я уже писал где-то в другом комменте, что речь идет о системе аналогичной той которой пользуются хостинги, когда продается, грубо говоря, изолированный кусок памяти+диска+процессора. И если клиент все израсходовал — сам себе буратино, но должна быть возможность оперативно докупить.

Да, уже ниже обсудили.

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

Спасибо.

Ответил ниже.

Если честно, я предлагаю именно продавать ресурсы + права на использование и некоим образом это не скрывать, потому что это реально и есть то, что продается в SaaS. Только не надо понимать слишком буквально. О том что написано на сайте разработчика в разделе «pricing» должны заботиться маркетологи, это их работа, я говорю только о принципе. Тем не менее я уверен что с помощью простых примеров, понятных среднему менеджеру, процессорное время и память можно конвертировать в пользователей, проекты и все остальное.

Ну хорошо, поробуйте прикинуть, что в данной области будет считаться «ресурсами» для пользователей сервиса.

Так то же самое и будет, нет? Память, процессорное время и дисковое пространство.

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

Ну, кому +10, а кому и +1000.

То есть мы опять возвращаемся к тому что в общем случае количество лицензий = количеству пользователей.

Есть, но это скорее исключения.

Не знал что у них такая система. Это конечно более интересно. Но что будет если вдруг сложится ситуация когда всем понадобиться зайти одновременно?

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

У 37signals кроме Basecamp есть еще много чего, например Highrise: highrisehq.com/signup
Я привел в пример heroku, разве там сложная формула?