Есть много противоречивых целей, которые нужно учитывать при выборе ЕРП системы:
Автоматизация принятия решений.
Управленческая отчётность.
Публичная отчётность.
Внедрение технологий, консалтинг.
Снижение затрат.
Публичная коммуникация, когда внедрение это просто своего рода гандикап.
Прочие более мелкие цели и задачи.
Моё ИМХО сегодня для многих компаний стратегически верно опираться на тиражные решения изменяемые настройками, вместо доработок типовой логики готовых программ чаще менять бизнес свои бизнес процессы.
Можно развивать систему, внося последовательные локальные доработки и комплексные подсистемы в типовой функционал, это легче!
Понятно, что за большие деньги можно собрать проект на любой платформе на любом языке, но для этого нужна высокая квалификация аналитиков, которые должны породить связную бизнес логику, ну и достаточно большое время на устранение багов.
Поэтому подход 1с с готовыми отраслевыми конфигурациями выглядит весьма продуктивно.
Мне резануло слух, что в SAR есть "трехступенчатая архитектура безопасности", имхо, всегда важнее организация процессов, платформа вторична.
Хотя в главном соглашусь, квалификация специалистов важна, в этом смысле "дорогая платформа" может привлекательней потому, что она имеет большие бюджеты, и специалисты имеют опыт комплексного проектирования бизнес процессов с нуля, если нужно заказчику.
Вот здесь падает с ошибкой: если инструменты<>неопределено тогда ЧтениеJSON = Новый ЧтениеJSON; ЧтениеJSON.УстановитьСтроку(инструменты); схема = ПрочитатьJSON(ЧтениеJSON); ЧтениеJSON.Закрыть(); данные.Вставить("tools",схема); конецесли; инструменты имеет тип инструменты, а что подставлять не понятно, схему JSON? Зачем ее отправлять на сайт? Не получается короче вызвать функцию GetGoodsBalance на последней версии AILIB1C_31
Что-то не нахожу реквизита как связать обработчик и инструмент, как бот насоветовал: "В карточке инструмента (элемент справочника БИИ_Инструменты) имя функции-обработчика указывается в реквизите, который обычно называется "Обработчик" или "ИмяОбработчика" (название может отличаться в зависимости от реализации расширения)."
Мне идея кажется очень даже интересной. Хорошо бы доработать: - оценка достоверности рекомендаций, - интеграция с государственными системами здравоохранения, - юридические аспекты, - финансирование краундфандинг. А в перспективе хотелось бы иметь саморазвивающуюся систему которая будет развиваться на основе введенных результатов применения рекомендаций (например на основе данных о покупках и использовании мед.средств)
Опыт можно и подешевле купить без программы
Есть много противоречивых целей, которые нужно учитывать при выборе ЕРП системы:
Автоматизация принятия решений.
Управленческая отчётность.
Публичная отчётность.
Внедрение технологий, консалтинг.
Снижение затрат.
Публичная коммуникация, когда внедрение это просто своего рода гандикап.
Прочие более мелкие цели и задачи.
Моё ИМХО сегодня для многих компаний стратегически верно опираться на тиражные решения изменяемые настройками, вместо доработок типовой логики готовых программ чаще менять бизнес свои бизнес процессы.
Можно развивать систему, внося последовательные локальные доработки и комплексные подсистемы в типовой функционал, это легче!
Понятно, что за большие деньги можно собрать проект на любой платформе на любом языке, но для этого нужна высокая квалификация аналитиков, которые должны породить связную бизнес логику, ну и достаточно большое время на устранение багов.
Поэтому подход 1с с готовыми отраслевыми конфигурациями выглядит весьма продуктивно.
Мне резануло слух, что в SAR есть "трехступенчатая архитектура безопасности", имхо, всегда важнее организация процессов, платформа вторична.
Хотя в главном соглашусь, квалификация специалистов важна, в этом смысле "дорогая платформа" может привлекательней потому, что она имеет большие бюджеты, и специалисты имеют опыт комплексного проектирования бизнес процессов с нуля, если нужно заказчику.
Это запрещено политикой 1с
Вот здесь падает с ошибкой:
если инструменты<>неопределено тогда
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(инструменты);
схема = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
данные.Вставить("tools",схема);
конецесли;
инструменты имеет тип инструменты, а что подставлять не понятно, схему JSON?
Зачем ее отправлять на сайт?
Не получается короче вызвать функцию GetGoodsBalance на последней версии AILIB1C_31
Что-то не нахожу реквизита как связать обработчик и инструмент, как бот насоветовал:
"В карточке инструмента (элемент справочника БИИ_Инструменты) имя функции-обработчика указывается в реквизите, который обычно называется "Обработчик" или "ИмяОбработчика" (название может отличаться в зависимости от реализации расширения)."
Ну ну, умирает. Это при какой такой нагрузке ЕРП умирает?
Мне идея кажется очень даже интересной. Хорошо бы доработать:
- оценка достоверности рекомендаций,
- интеграция с государственными системами здравоохранения,
- юридические аспекты,
- финансирование краундфандинг.
А в перспективе хотелось бы иметь саморазвивающуюся систему которая будет развиваться на основе введенных результатов применения рекомендаций (например на основе данных о покупках и использовании мед.средств)