Из практики, больше всего проблеме из-за структурных различий в интегрируемых системах. Например неоднозначные связи (один и тот же объект источник может загружаться в разные приемники), архитектурные различия в обработке данных (одна система поддерживает работу «задним числом, а другая нет). Таких проблемы бывают конечно всегда, но при интеграции систем сделанных на одной платформе, или еще лучше одним поставщиком, этих проблему будет существенно меньше.
А зачем вы сравниваете свое решение с 1С? Хотите сделать рекламу «нападением» на армию 1С-ников, которых, думаю существенно больше? Пытаться «выехать» за счет «унижения» другого не самый честный способ (хотя думаю унизить будет сложно, все же 1С хорошая платформа для решения задач для которых она предназначена). Многие 1С-ники сами не в восторге от своего инструмента, но им она даёт больше чем другие. И многим будет интересно просто узнать про возможности других систем.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
С чего вы взяли что весь «головняк» из-за работы задним числом?
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
Разница в том, что этот «один» поставщик точно имеет актуальную информацию по планам развития и оперативно актуализирует это самую «интеграцию». Когда поставщика 2, один обязательно «прошляпит» изменения у другого.
lsFusion и 1С это платформы для создания прикладных решений. Следовательно важны не они сами по себе, а прикладные решения который создаются с их использованием. Главная цель для них это «нести» пользу конечному пользователю. Потребители по большому счёту не важно на чем он работает. По этому показателю 1С является лидером. Конкуренция с 1С начнется только тогда, когда конечному потребителю будут предоставлены все те же удобства что он имеет сейчас.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
Так любая интеграция это большая головная боль. Особенно когда интегрируемые системы развиваются независимо в своих интересах. Кто будет заниматься актуализацией? В результате, какой заказчик захочет жить в условиях постоянной опасности что в один прекрасный день, что-то может не работать?
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область.
Это у вас опыт внедрения и того и того говорит?
на каком-то мейнстримовом языке вроде java/c#/go
Решение делается ведь не на языке. Язык не важен. Важен фреймворк на котором сделано решение. Писать под каждое решение свой фреёмворк точно не в интересах конечного заказчика.
Вы себе представляете что это такое? Думаете он так вот сел, и решил посчитать налоги и все? Думаете ему ничего из «управленческих» данных ничего для этого не нужно? Ему это как вводить, вручную?
Они (бензины) же из разных пистолетов наливаются. Какой пистолет взял, тем и заправляюсь, зачем это в приложении указывать?
Не все заправки работают по принципу универсама (что захотел то и взял). В некоторых нужно чтобы продавец разрешил.
Не на всех заправках бензин может сразу «литься» из любого пистолета.
МК-85 это первый «компьютер» на котором я писал программу. Правда слово «писал» звучит громко, скорее переписывал из книжки с примерами которая была у него в комплекте. В комплекте еще был прозрачный трафарет на клавиатуру с русскими буквами. И книжки с примерами программ. Например игра «Больше-меньше». А разъём питания у него был по форме похож на miniUSB. Лежит где-то сейчас у родителей, не удивлюсь если еще работает.
Ну GPG это открытое ПО, плагины были для разных почтовых клиентов, даже для outlook встречались. Нет только инструментов для чтения таких писем в веб-клиенте. А там, никакой проблемы по сути нет. Для шифрования переписки все уже давно придумано и сделано давно.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
Это у вас опыт внедрения и того и того говорит?
Решение делается ведь не на языке. Язык не важен. Важен фреймворк на котором сделано решение. Писать под каждое решение свой фреёмворк точно не в интересах конечного заказчика.
И эту фильтрацию нужно делать в каждом месте? А если её нужно подкорректировать?
Вы себе представляете что это такое? Думаете он так вот сел, и решил посчитать налоги и все? Думаете ему ничего из «управленческих» данных ничего для этого не нужно? Ему это как вводить, вручную?
Не все заправки работают по принципу универсама (что захотел то и взял). В некоторых нужно чтобы продавец разрешил.
Не на всех заправках бензин может сразу «литься» из любого пистолета.