Прохожий2Спросите ASU - о его опыте проектирования/программирования. Нужна ли ему 1С/SAP... ? А заодно и о СУБД, которая используется на внедренных им проектах...В начале мне бы хотелось сделать одно замечание. ERP-система является сложной системой, сложной с точки зрения ее структуры, организации. Но структурная сложность не всегда сопровождается сложностью семантической, то есть, структурно сложный объект может быть адекватно воспринят, то есть, смысл сложного объекта не обязан быть сложным для восприятия.
При всех отличиях между 1С/SAP и "самописными" системами их объединяет то, что смысловые модели положенные в основу проектов сложны. Как следствие, есть проблемы разработки, внедрения, сопровождения и развития. Для примера, по оценкам специалистов SAP на создание R/3 потребовалось 2500 - 5000 чел.-лет. Примерно такая же оценка и специалистов Oracle. Мы изменили подход к получению моделей предприятия и его системы управления, и трудоемкость проекта снизилась до 10 чел.-лет и менее того. Это кажется невероятным, но данная оценка подкреплена опытом.
Однако, если предположить , что ERP-систему можно создать за столь небольшое время, то граница между тиражной и самописной системой исчезает (поскольку сегодня доводка тиражной системы для конкретного предприятия является более трудоемкой операцией). Но тогда и дискуссия на эту тему не имеет смысла. Практически любое предприятие численностью от 500 чел. может создать собственную информационную систему, не уступающую по функционалу именитым "собратьям", но превосходящую их по своей адаптированности к специфике предприятия.

То, что сказано выше о трудоемкости разработки, может быть спроецировано на используемые инструментальные средства (языки и среды программирования, CASE-системы проектирования, СУБД и пр.). Чем сложнее исходные модели, тем более сложные (и дорогие) средства разработки применяются, тем выше административные и квалификационные требования к людям, входящим в команду разработчиков и консультантов, занимающихся внедрением.

saasa ASU
Для примера, по оценкам специалистов SAP на создание R/3 потребовалось 2500 - 5000 чел.-лет. Примерно такая же оценка и специалистов Oracle.

Они наверно считали время на разработку всех отраслевых решений.
+ SAPу уже 30 лет. :)Да, SAP 30 лет. В 1979 году вышла MRP-система R/2 ориентированная на IBM-360/370. R/3 вышла в 1992 году.
Я не могу сказать, какие зптраты времени они включили в расчеты трудоемкости (это не оглашалось, да и сама оценка имеет широкий диапазон), но я не думаю, что отраслевые различия столь значительны, с точки зрения построения системы.

Прохожий2 ASU...Мы изменили подход к получению моделей предприятия и его системы управления, и трудоемкость проекта снизилась до 10 чел.-лет и менее того. Это кажется невероятным, но данная оценка подкреплена опытом Есть ли какие-нибудь публикации/материалы по этому поводу?Пока нет. Мы не делаем секретов из своей работы, но писать статьи и книги - не мой удел.

saasa ASUЯ не могу сказать, какие зптраты времени они включили в расчеты трудоемкости (это не оглашалось, да и сама оценка имеет широкий диапазон), но я не думаю, что отраслевые различия столь значительны, с точки зрения построения системы
Отраслевые решения это практически самостоятельные продукты.
Различий очень многоЭто, как раз, зависит от модели. Если говорить, о промышленных предприятиях, то мы рассматривали модели по всей цепочке переделов от добывающих предприятий до предприятий утилизации; по объемам производства от массовых до индивидуальных. С нашей точки зрения, различия очень незначительны. Например, есть некое промышленное предприятие выпускающее серийную продукцию (металл, трубы, станки или т.п.), есть на этом предприятии ОГМ (отдел главного механика), который отвечает за ремонт основного технологического оборудования. С точки зрения R/3 (и ей подобных) подсистмы основного производства и подсистема ремонтного производства - это разные подсистемы. Для нас - это просто производство в обоих случаях. И если смысл производства понимается на предприятии, то им достаточно инсталлировать еще один экземпляр подсистемы "Производства" и настроить ее технологическую часть на ремонт оборудования. Такое решение удобно (поскольку пользователям нет необходимости переучиваться), экономично (не надо платить дополнительные деньги), эффективно (т.к. установка подсистемы происходит быстро).
То же самое можно сказать и о других подсистемах.

Прохожий2 ASU...Мы не делаем секретов из своей работы, но писать статьи и книги - не мой удел. Приехать к вам на месте посмотреть/послушать в каком-либо мало-мальски систематизированном виде - реально?Да, вполне. Только лучше во второй половине октября, если хотить посмотреть на процесс внедрения, то в ноябре.

mazzy ASUДля примера, по оценкам специалистов SAP на создание R/3 потребовалось 2500 - 5000 чел.-лет. Примерно такая же оценка и специалистов OracleНеее. Это создание, развитие до сегодняшнего уровня и развитие системыДанные по SAP датированы 1994 годом, по Oracle - 2000.
mazzy ASUМы изменили подход к получению моделей предприятия и его системы управления, и трудоемкость проекта снизилась до 10 чел.-лет и менее тогоСоздать с нуля - это дело нехитрое. Вы обеспечте поддержку, вы обеспечте развитие вашей системы в изменяющихся условиях...Обеспечиваем.
mazzyВот выше тут писали про то, что используют самые современные технологии - Visual Studio + MS SQL. Дык, это не самые современные. Самые современные - это Юкон + Лонгхорн :)Мне кажется, что потребности в каких-то суперсовременных средствах разработки преувеличены. Они (мифические потребности) насаждаются самими разработчиками этих "суперсовременных" средств.
mazzyВот окончательно выйдую эти суперсовременности - попереводите свою суперсистему. А затем выйдет что-нибудь еще. Вам снова придется развивать и... обеспечивать совместимостьМы не используем ничего "супер", и... не имеем данных проблем.

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

LSVОдин из недостатков внедрения собственных продуктов - страшная нехватка времени. На всё про всё даётся полгода. За это время невозможно сделать всё "по уму", описать и формализировать, а после внедрения всё равно мало времени на переделку "по уму"... Это и есть главный и справедливый аргумент у вышеописаных личностей. Но это не означает, что это не имеет смыслаВозможно нехватка времени - это не сама проблема, а следствие проблемы... Проблемой, скорее всего, является различие в понимании целей, методов и ресурсов у руководства предприятия и команды разработчиков. Если есть общность взглядов, то проблема нехватки времени просто не возникает.
Поэтому, на мой взгляд, необходимо согласовать цели системы с руководством предприятия. Но! Согласование целей не означает принятия/отторжение целей руководства . Нет ничего удивительного в том, что очень немногие руководители задумываются над тем, для чего (зачем) они управляют. Показать руководству цели управления с системной точки зрения - задача создателей системы управлений (информационной системы, в том числе).
Нет ничего удивительного и в том, что руководство предприятия редко задумывается и над тем как оно управляет. Один руководитель привык "вызывать на ковер", другой проводит бесконечные "совещания". А как правильно управлять? На этот вопрос нельзя ответить однозначно, поскольку ответ зависит от внешних и внутренних условий. Но разработчики системы управления должны показать руководству критерии выбора и применимости того или иного метода управления.
Наконец, важно понимать то, какие ресурсы требуются для создания системы и ее поддержания в работоспособном состоянии. И здесь, можно столкнуться с той же проблемой: далеко не каждый руководитель способен четко (аргументированно!) сказать, чем он управляет (спектр вариантов ответов бывает весьма широк: руковожу людьми, отделом, проектом, исполнением плана и т.д.).
Для того, чтобы снять эти и подобные вопросы удобно использовать простые семантические модели объекта и субъекта управления (в данном контексте: предприятия и его управляющего аппарата). Это позволяет быстро находить общее понимание все тех же целей, методов и ресурсов (время - это тоже ресурс). IMHO, конечно...