Здравствуйте, IT, Вы писали:


IT> В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.

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

> Да, а такие компании как РосТлеком, Ленсвязь, Toyota,
> Энергомаш, Перекресток, Исток, Волгоградский Аллюминий,
> MTV, Marvel, Osko, Алтайагропромснаб, Гипермаркет О"Кей,
> Группа компаний DIXIS, ДелтаСпорт, Останкинский молочный
> комбинат, Первоуральский новотрубный завод, РУССО, Ригла,
> Техносила, Тинькофф — это я говорю про тех людей, которые
> выбрали Axapt'у. Про другие системы не буду рассказывать,
> так как не очень с ними знаком. Это по твоему мелкие компании ?

Ростелеком будет работать на том, что для него выберет Связьинвест Или
выбрал.
Такие конторы, как Перекресток, Исток, ДельтаСпорт, Техносила и подобные — суть
торговые фирмы, с известными бизнес-процессами. На Энергомаше уже давно
внедряется R/3. Toyota — это где? В Москве?

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

Здравствуйте, S-SH, Вы писали:


SS>Ростелеком будет работать на том, что для него выберет Связьинвест Или
SS>выбрал.

Ростелеком будет работать на Axapta. Он уже на нем работает, и будет на нем работать, так как софт уже куплен, работает и люди довольно. И нокто не пойдет на то, чтобы выбросить деньги потраченные на внедрение.
Да Связьинвест выбрал Oracle Application (если это конечно можно так назвать ). Но если ты внимательно следил за их пресс-релизами, то ты знаешь, что они будут внедрять его только там, где еще не внедрены другие системы.
Более того, Связьинвест не будет работать на том, что выберет.. ..потому, что выбора там, как такового не было. Не буду выносить эту историю в открытый форум, но те кто следили за этими событиями сами все понимают — информации наружу вышло достаточно, для того чтобы каждый смог сделать соответствующие выводы...

SS>Такие конторы, как Перекресток, Исток, ДельтаСпорт, Техносила и подобные — суть
SS>торговые фирмы, с известными бизнес-процессами.

Хм.. А ты хочешь писать не зная бизнес-процессов...

SS> На Энергомаше уже давно
SS>внедряется R/3.

Лично я могу назвать три Энергомаша. Ты про какой говоришь ?

SS>Toyota — это где? В Москве?

Да.

SS>Но любое количество подобных примеров не доказывает правильности выбора. Оно
SS>лишь доказывает правильность маркетинга конкретной системы.

Просто у меня есть опят, что такая-то такая-то компания колбасилась пять лет пытаясь разработать что-то свое,но поняла, что лучше довериться профессионалам ..... Блин, да что я буду рассказывать — прочитай любой пресс релиз о внедрении....

p.s. На самом деле это философский вопрос и каждый его решает сам. Что бы не выбрали — внедрять готовое или писать свое — все равно, опыт подсказывает, что поставленные цели редко становятся достигнутыми — речь идет лишь о приближении к мечте...

> SS>Ростелеком будет работать на том, что для него выберет Связьинвест
> SS>Или выбрал.
>
> Ростелеком будет работать на Axapta. Он уже на нем работает,
> и будет на нем работать, так как софт уже куплен, работает
> и люди довольно. И нокто не пойдет на то, чтобы выбросить
> деньги потраченные на внедрение.

К примеру, ежели я доволен своим Delphi 3, и деньги на софт потрачены, а
начальник мне говорит, что надо переходить на VS.Net, мне его не слушаться? Так
что это все неоднозначно.

> SS>Такие конторы, как Перекресток, Исток, ДельтаСпорт,
> SS>Техносила и подобные — суть торговые фирмы,
> SS>с известными бизнес-процессами.
> Хм.. А ты хочешь писать не зная бизнес-процессов...

Я?!! Они фирме-разработчику известны. А автор ветки имеет в виду нетиповые
бизнес-процессы, о которых разработчик и не догадывался.

> SS> На Энергомаше уже давно
> SS>внедряется R/3.
>
> Лично я могу назвать три Энергомаша. Ты про какой говоришь ?

Так, начинается... Есть разница? Ты назвал фирму Энергомаш. Я тоже. Пусть это
будут две разные фирмы с похожим названием. И что это меняет? Вроде речь не о
том, какую систему покупать, а о том стоит ли покупать.

> SS>Toyota — это где? В Москве?
> Да.

Вроде речь про крупные фирмы была. А не про их региональные представительства.

> Блин, да что я буду рассказывать — прочитай любой пресс релиз
> о внедрении....

Примерно так — "мы внедряли, мы внедряли, наши пальчики устали"
К сожалению, "ошибкой было бы думать", что внедрение является одноразовой
задачей.
Это — длительный, бесконечный процесс. Зависимость в этом процессе от сторонней
фирмы есть не самая удачная строка бюджета.

Здравствуйте, S-SH, Вы писали:

SS>Это — длительный, бесконечный процесс. Зависимость в этом процессе от сторонней
SS>фирмы есть не самая удачная строка бюджета.

Я раньше работал со стороны заказчика. То есть на предприятии, которая приобрела Axapt'у. Предприятие называется Карачаровский Механический Завод (тут скрывать нечего). Уже в самом начале проекта было ясно, что на пользоваться услугами консалтеров и сотронних программистов мы позволить себе не можем. Было принято решение все изучать самим. Ну не было у нас в бюджете такой строки

На самом деле я не говорю, что не нужно разрабатывать — я лишь говорю, что разрабатывать следует не с нуля, а взяв за основу какой-то Framework.
Несколько далекий пример — разработка на чистом WinAPI или MFC(VCL). Решая писать на MFC ты не говоришь, что теперь у тебя лишняя строка в бюджете — ты говоришь, что надо просто изучить MFC — в результате я смогу вести разработку более быстро, а следовательно дешево.

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

Здравствуйте, Slick, Вы писали:

S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.

S>Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.

S>Возникает вопрос, какие средства разработки использовать?

S>Естественно, кое-каие соображения есть, но хочется услышать мнения общественности.

S>Кроссплатформенность не требуется. Все должно работать на NT-сервере. Клиенты — тоже под Windows.

S> — Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.

S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server

S>- Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.

S>- Вопрос шифрования данных циркулирующих в системе.

S>Вобщем вот такие вопросы. Благодарен за любые ответы, мысли, мнения.


Все известные промышленные ERP писаны на С++, сейчас J2EE проталкивают туда, но лидерство по-прежнему у классики.

И вряд ли ситуация изменится.

Здравствуйте, Аноним, Вы писали:

А>Все известные промышленные ERP писаны на С++, сейчас J2EE проталкивают туда, но лидерство по-прежнему у классики.

А>И вряд ли ситуация изменится.

Да, похоже на то.

Это очень консервативная область IT.
Внедрение на большом предприятии занимает месяцы — годы, цена систем — порядок миллионов и десятков миллионов, поэтому там, исповедуемый в Java принцип — дешево и сердито — не катит

Какую-то мелочевку может на Java и лабают, но это все крохи с ERP-шоного стола

Здравствуйте, <Аноним>, Вы писали:


А>Все известные промышленные ERP писаны на С++, сейчас J2EE проталкивают туда, но лидерство по-прежнему у классики.
А>И вряд ли ситуация изменится.

Как правило написание ERP системы начинается с написания своего метаязыка, на котором уже и разрабатывается функционал. Примеры ? Axapta, SAP, Галактика ... тот же 1С.

Сам метаязык как правило пишется на 1С.

P.S. М2 — написан на Дельфи (хотя я не скажу, что это удачная система); Platinum — сишное ядро, интерфейс и отчеты на Дельфи. Парус сейчас кажется на .Net переписывается.

Здравствуйте, DemAS, Вы писали:

DAS> P.S. М2 — написан на Дельфи (хотя я не скажу, что это удачная система); Platinum — сишное ядро, интерфейс и отчеты на Дельфи. Парус сейчас кажется на .Net переписывается.

Парус 8 на Дельфи, на .NET не переписывается.

Здравствуйте, Slick, Вы писали:

S>Какую-то мелочевку может на Java и лабают, но это все крохи с ERP-шоного стола

На джаве как раз самые тяжелые системы сейчас и делают

Здравствуйте, AndrewVK, Вы писали:

AVK>Парус 8 на Дельфи, на .NET не переписывается.

Может быть. Но была информация, что они разработчиков под .Net набирают.

Здравствуйте, S-SH, Вы писали:

SS>Это — длительный, бесконечный процесс. Зависимость в этом процессе от сторонней
SS>фирмы есть не самая удачная строка бюджета.

Тут приходится выбирать между преимуществами, если они есть , самопальной системы и "стандартной".
А зависимость будет в обоих случаях, и неизвестно, где она будет сильнее.

Здравствуйте, AndrewVK, Вы писали:

AVK>На джаве как раз самые тяжелые системы сейчас и делают

А тебе самому-то джава нравится?

Здравствуйте, DemAS, Вы писали:

IT>> В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.

DAS> Как правило все современные ERP имеют средства разработки, позволяющие модифицировать их под себя.

Это как раз понятно, иначе бы их никто не пользовал бы, а если бы и пользовал, то разработчики тратили бы больше на сапорт, чем получали бы денег... хотя если всё правильно обставить, то можно сделать неплохой бизнес на лохах. И между прочим некоторые делали, была (может и сейчас есть) конторка, которая в своё время окучила центробанк, так там

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

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

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

Здравствуйте, Slick, Вы писали:

AVK>>На джаве как раз самые тяжелые системы сейчас и делают

S>А тебе самому-то джава нравится?

Что значит нравится? Неплохое средство, не хуже дотнета.

Здравствуйте, DemAS, Вы писали:

DAS> Может быть. Но была информация, что они разработчиков под .Net набирают.

Это другой проект

Здравствуйте, Slick, Вы писали:
Как раз занимаюсь разработкой ERP.
Хочу указать некие точки, чтобы вам не наступить на мои грабли.
На чем будет написана система не столь важно Java или .NET. мы пишем под .NET.
У вас сразу образуется ряд задач требующих динамики, как при формировании классов, так и при создании метоописаний/ну и интерфейсов.
Поэтому в качестве 2ого уровня приложения: советую взять любой из существующих интерпретаторов — Perl/Python/Smalltalk.
Дальше обратитесь либо к RPC и т.д. или к SOAP — как мы
На чем вы будете писать клиентскую часть не важно. На чем удобнее.
Конечно, вы можете написать и свой интерпретатор... и встроить его не только в промежуточный слой — но и клиентскую часть. Мы выбрали Scripting Host + VBA от MS. т.е. велосипедов изобретать не стали.
Все что я написал, было рождено в муках и довольно хорошо обоснованно.
Хотя не зная вашей предметной области мне трудно что либо советовать. Наверное наше решение не слишком "быстрое".. даже при медленном/Application Server — слое, ERP способна решать реалтаймовые задачи. Все зависит от оборудования.
В любом случае удачи вам!
Если возникнут вопросы — готов сотрудничать

Здравствуйте, NetStyler, Вы писали:

NS>Как раз занимаюсь разработкой ERP.
NS>Хочу указать некие точки, чтобы вам не наступить на мои грабли.
NS>На чем будет написана система не столь важно Java или .NET. мы пишем под .NET.

Большое спасибо за советы.

И все же я хочу уточнить один, ключевой с моей точки зрения моомент.

Чем обосновывается решение применять .NET или Java в ядре системы? Почему не следовать традиционной практике разработки подобных систем, предполагающей применерие С++? Действительно хочу разабраться. Какие за и против по всем трем кандидатам: С++, .NET, Java

Здравствуйте, Slick, Вы писали:

S>Чем обосновывается решение применять .NET или Java в ядре системы?

Надежнее код, нет утечек памяти, невозможна случайная порча памяти.

S> Почему не следовать традиционной практике разработки подобных систем, предполагающей применерие С++?

Больше работы, особенно по отладке.

S> Действительно хочу разабраться. Какие за и против по всем трем кандидатам: С++, .NET, Java

Между .NET и Java за и против простые. Плюсы нета
1) Поддрежка МСовских enterprise технологий — serviced components, MSMQ и т.п.
2) Простота взаимодействия с legacy-кодом

Плюс джавы — больше количество родных решений — EJB, JDO и т.п.

Здравствуйте, Slick, Вы писали:
S>Большое спасибо за советы.
S>И все же я хочу уточнить один, ключевой с моей точки зрения моомент.
S>Чем обосновывается решение применять .NET или Java в ядре системы? Почему не следовать традиционной практике разработки подобных систем, предполагающей применерие С++? Действительно хочу разабраться. Какие за и против по всем трем кандидатам: С++, .NET, Java
1. С++ Выигрываем в быстродействии. Проигрываем в "стоимости разработки". Под стоимостью я подразоумеваю не только затраты на программистов, но и высокие временные затраты на разработку и отладку. У С# и Java эти пороги гараздо скромнее.
2. С# и Java — платформы похожие. Но если вы используете линейки продукции Microsoft/MS SQL и т.д. — выбор очивидет. Здесь самое главное не устроить войну идеологий, а выбирать основываясь на принципе наименьшего сопротивления.
Задайтесь вопросом кто ваши клиенты — какое ПО они используют — какое ПО им проще поддерживать. Ответ придет к вам сам