|
23.03.2017, 14:52 | #1 |
Участник
|
Цитата:
Сообщение от mazzy
хм... давайте я попробую в последний раз.
корпоративное приложение = любое приложение + корпоративные пользователи. корпоративные пользователи != обычные пользователи. корпоративные пользователи ~ много-много-много обычных пользователей. поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений. но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения". корпоративные пользователи в отличие от обычных пользователей имеют влияние, хоть и опосредованное, на производителя ПО. граничные случаи хороши наглядностью вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема. Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках. |
|
23.03.2017, 15:41 | #2 |
Участник
|
давайте.
Цитата:
Сообщение от AlexeyS
граничные случаи хороши наглядностью
вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема. Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках. только и вы тоже где-то вне контекста. или уводите разговор в сторону. если вам так угодно, пожалуйста, не меняя контекста, приведите полную цепочку рассуждений от вопроса, заданного в начале автором, через "написать с нуля", вплоть до вашего вывода. было. я ответил: поэтому - нет, не дешевле и мы все еще говорим: |
|
23.03.2017, 19:28 | #3 |
Banned
|
Цитата:
Originally Posted by ax_mct
Дешевле написать с нуля улучшенную версию чем мигрировать Цитата:
Например занесение рабочего времени/командировочных расходов через web-interface на базе AX EP и Sharepoint. Тормозит, не нравится интерфейс, требуются кастомизации в силу специфики. Берется open-source PHP как например time tracking http://www.kimai.org/ или похожее и кастомизируется. О какой миграции тут может быть речь? Какие-то свои шурупы, крюки и пристройки в AX которые образуют "свое", специфичное. Невозможно это переписать на другой язык, так как речь может быть только о миграции бизнеса на другую платформу с новой разработкой при необходимости. Но переписывание приложения что настолько в симбиозе - невозможно, нужен новые дырки в новых местах с другими шурупами. А писать "с нуля" - это я про кастомизации в новой системе с нуля. Мы же не ожидаем что кто-то после/из AX/D365 захочет написать свое ERP c нуля? Нет, этот кто-то возьмет как платформу что-то типа https://github.com/odoo/odoo и будет писать кастомизации с нуля. Потому как переносить старый код и старую логику прутик за прутиком - не эффективно. |
|
|
|