>>105134
Если на этом нельзя отжать/распилить бабла, то хуй ты что получишь, это я могу сказать точно. А если говорить вообще, то надо подумать, но мне таки кажется что мы договоримся до того что пилить надо по-честному, а не по-братски - современная номенклатура плохо представляет, откуда берется прибыль.

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

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

>>105135

>публикация информации о деятельности организаций вступает в разрез с правилами конкуренции.

С кем же конкурирует государство?

>>105136
С другими формами общественной организации. И с другими государствами, кроме того, но это разные уровни.

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

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

>>105134

> у большинства очко играет отдать ололо иннеровскую информацию третьему лицу

Уже достаточная причина, чтобы этого не делать.

> интегрированный комплекс систем такого рода мог бы быть внедрён в госсекторе

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

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

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

>>105140
Зато как удобно парализовать работу всех компаний, завязавшихся на единственный ERP.

Должен признаться, что ни фига не понял общей идеи ОПа.
Единой интегрированной системы быть не может, ибо у всякой крупноконторы особенности организации разные. Именно это превратило тот же пакет 1С в убер-комбайн из лаконичного калькулятора (которым он мог бы стать).
Есть всяческие CRM, разворачиваемые локально. Есть конструкторы типа SAP. Есть системы документооборота, внедряемые. Всё, разумеется, локально. Всё это, в некоторой мере, на правах SaaS.
Для не-ленивых есть конструкторы Java и C#, которые позволяют за пару дней развернуть средства учёта кадров, складов, хоть чего.
Дефицит ПО - не проблема. Проблемы возникают сбоку, когда начинает столкновение реальных потребностей и фантазий/пониманий разных людей, участвующих в процессе разработки/внедрения.
SaaS с доступом наружу или (данунах!) вращающийся на серверах левой конторы - это стёб. Хоть тот же Ростелеком предлагает подобные сервисы (o7.com), они предназначены для рашн-бизнесов, которые от IT-отделов, управляемого оборудования и квалифицированных кадров крайне удалены.

>>105135
Речь не о распилах/откатах.
>>105140

>Уже достаточная причина, чтобы этого не делать.

Да, однако, если распоряжение придёт сверху, то никуда они не денутся.

>Там все плохо с безопасностью, личную переписку каких-нибудь чиновников регулярно выкладывает в паблик.

Причём тут переписка? Да и проблема с доступом стоит не менее остро чем с классическими клиент-серверными приложениями.

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

Вот поэтому и нужна система. Система не экселька, она в уровни доступа умеет.

>Кроме того у каждой организации свое представление о том, что и как должна делать такая система и то, что подходит строительной компании, может не подойти IT корпорации и наоборот.

Никто и не говорит что бизнес процессы должны быть едины. Конечные формочки и алгоритмы вполне себе могут быть заточены напильником. Тем не менее есть международные стандарты отчётности, да и взаимодействие в рамках рынков, а также кроссотраслевых покупок-продаж и подрядов вполне можно стандартизировать.

>Поэтому они и держат целый штат программистов, которые допиливают систему под собственные нужды компании.

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

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

Если строить отдельный ЦОД под такую систему, то ещё как даст. Да и фишка скорее в бесшовной интеграции систем нескольких компаний. Я уже не говорю о уровне анализа, если компания будет иметь доступ не только к своим историческим данным, но и к данным контрагентов и конкурентов (допустим обезличенное среднее по рынку).
>>105142
Единой интегрированной системы быть не может, ибо у всякой крупноконторы особенности организации разные.
Никто и не говорит, что организация должна быть одинаковая. Одинаковым должен быть инструментарий и модули, связанные с взаимодействием.

>Именно это превратило тот же пакет 1С в убер-комбайн из лаконичного калькулятора (которым он мог бы стать).

Нужно быть конкретнее, у 1С много продуктов же.

>Есть конструкторы типа SAP.

Опять таки у сапа тьма продуктов. И какой-нибудь R/3 они будут допиливать как для производителей презервативов так и для горно-обогатительного комбината. Кроме того, если мы имеем дело с многопрофильным бизнесом - то вполне себе могут пилить и для банков и для производства в рамках одного холдинга и одного продукта.

>Есть системы документооборота, внедряемые. Всё, разумеется, локально.

СМЭВ? Не не слышали.

>Java и C#
>за пару дней развернуть средства учёта кадров, складов, хоть чего.

ORLY?

>Проблемы возникают сбоку, когда начинает столкновение реальных потребностей и фантазий/пониманий разных людей, участвующих в процессе разработки/внедрения.

Опять таки, если что-то приходит сверху, как например формы статистики или налоговой - то все заполняют и никуда от этого не деться.

>SaaS с доступом наружу или (данунах!) вращающийся на серверах левой конторы - это стёб.

Тем не менее крупнейшие вендоры (SAP, Oracle, MS) уже вывели некоторые продукты в облачный SAAS.

>>105151

>Речь не о распилах/откатах.

Ну это ты сейчас так думакешь. В особенности если считаешь что дело только в формочках и алгоритмах.

>Тем не менее крупнейшие вендоры (SAP, Oracle, MS) уже вывели некоторые продукты в облачный SAAS.

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

>>105151

> Да, однако, если распоряжение придёт сверху, то никуда они не денутся.

Скорее будет как и с бухгалтерией - одна для отчетов наверх, другая для реальной работы.

> Причём тут переписка?

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

> Да и проблема с доступом стоит не менее остро чем с классическими клиент-серверными приложениями.

Если система никак не смотрит во внешнюю сеть и с ней работает только подписавший NDA персонал то безопасность обеспечить куда проще, чем когда система открыта всем ветрам и работают с ней анонимные налоговые инспекторы и их родственники.

> Тем не менее есть международные стандарты отчётности, да и взаимодействие в рамках рынков, а также кроссотраслевых покупок-продаж и подрядов вполне можно стандартизировать.

Стандартизация форматов это хорошо, когда форматы хорошо описаны и продуманы. И речь не идет о выносе всего в один сервер/кластер.

> Под нужды вполне можно оставить небольшой штат, который будет отрисовывать кастомные формочки и алгоритмы.

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

> Если строить отдельный ЦОД под такую систему, то ещё как даст.

Под ЦОД нужно строить отдельное здание, строить резервирование по каналам, электропитанию, охлаждению, при этом стоимость конечного сервера и общее их количество не измениться.

> Да и фишка скорее в бесшовной интеграции систем нескольких компаний.

В таких случаях обычно просто договариваются о API и все замечательно работает.

> допустим обезличенное среднее по рынку

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

Я вот не понимаю, ОП, зачем ты продолжаешь настаивать на своём? Что конкретно тебя не устраивает? Почему ты считаешь, что SaaS имеет перспективы поглощения всего и вся? Тебе уже всё расписали, твоё несогласие не делает крупных заказчиков твоими. Ты советуешься с себе подобными, тебе отвечают.

>>105154

>Скорее будет как и с бухгалтерией - одна для отчетов наверх, другая для реальной работы.

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

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

И тем не менее, какой-нибудь консолидированный отчёт в эксельке они могут при любой системе потерять.

>Если система никак не смотрит во внешнюю сеть и с ней работает только подписавший NDA персонал то безопасность обеспечить куда проще, чем когда система открыта всем ветрам и работают с ней анонимные налоговые инспекторы и их родственники.

Современные системы в большинстве своём связаны с интернетами. А пользователей "внешних" и "внутренних" вполне можно разграничить ролевой политикой.

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

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

>Или просто ложить систему в ответственный для конкурентов момент.

Опять таки, можно распределять ресурсы. Например 70% - пользователи внутренние, 30% внешние. Если атака будет проводится на более низких уровнях - то я не представляю чем можно положить ЦОДик.

> Если строить отдельный ЦОД под такую систему, то ещё как даст.
>Под ЦОД нужно строить отдельное здание, строить резервирование по каналам, электропитанию, охлаждению, при этом стоимость конечного сервера и общее их количество не измениться.

Но это классическое облако же. Олсо, в сраче о том что облака только маркетинговый ход я участвовать неготов.

>В таких случаях обычно просто договариваются о API и все замечательно работает.

Как проще собрать отчёт по отрасли - если данные будут тянуться с сотен серверов в разных точках мира, с разными БД под API или из одной базы данных, например?

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

Как ты будешь обрабатывать налоговые отчёты? Кроме того, степень детализации в них никакущая.
>>105160

>Я вот не понимаю, ОП, зачем ты продолжаешь настаивать на своём?

Я вот не понимаю /б, почему в нём есть треды?

>Что конкретно тебя не устраивает?

Что нет единой базы данных по отраслям, потому, что всякие росстаты сосут?

>Почему ты считаешь, что SaaS имеет перспективы поглощения всего и вся?

Посмотри рынки SaaS в динамике.

>Тебе уже всё расписали, твоё несогласие не делает крупных заказчиков твоими.

Вау. На новере можно найти ЗАКАЗЧИКА?

>Ты советуешься с себе подобными, тебе отвечают.

Я стараюсь пошире раскрыть тему же.

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

>Опять таки, можно распределять ресурсы. Например 70% - пользователи внутренние, 30% внешние. Если атака будет проводится на более низких уровнях - то я не представляю чем можно положить ЦОДик.

моджахед и гранаты
узбеки и экскаватор
электрики и перенапряжения
военные и аппараты РЭБ
разведка и завербованный персонал твоей системы
владелец системы и планы мирового господства

>>105261

>Современные системы в большинстве своём связаны с интернетами

РЖД, Газпром, Сбербанк
был кто-то ещё, у кого тоже свои интернеты с блэк-джеком и шлюхами

>>105261

> И тем не менее, какой-нибудь консолидированный отчёт в эксельке они могут при любой системе потерять.

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

> А пользователей "внешних" и "внутренних" вполне можно разграничить ролевой политикой.

В данном случае "внутренние" пользователи почти ничем не рискуют даже в случае практически прямого саботажа.

> Если атака будет проводится на более низких уровнях - то я не представляю чем можно положить ЦОДик.

Например строим запрос, который будет косвенно несколько раз вызывать самого себя. Выполняем этот запрос и наблюдаем как система атакует сама себя.

> Но это классическое облако же.

Но ведь облакам тоже нужна надежная инфраструктура, иначе все развалиться после первого же отключения электроэнергии.

> Как проще собрать отчёт по отрасли - если данные будут тянуться с сотен серверов в разных точках мира, с разными БД под API или из одной базы данных, например?

В случае унификации API не имеет значения, что и где крутиться "под капотом".

> Как ты будешь обрабатывать налоговые отчёты?

Добавлением дополнительных выборок к текущей системе.

> Кроме того, степень детализации в них никакущая.

А так ли нужна детализация когда нужны данные в среднем по отрасли?