Когда предприятию необходим собственный полноценный отдел АСУ?

← →
Alx2 © (2004-08-25 12:01) [0]

Наше предприятие занимается производством теплоизоляционных материалов. При этом производство расширяется - появляются новые структурные подразделения. И уже второй год стоит задача реализации АСУ.
Собственно, вопрос: в каком случае (с какого момента развития) предприятию необходим собственный полноценный отдел АСУ, занимающийся постановкой, внедрением, программированием и документированием? Или все это выгоднее оставить делать подрядчику? Ситуация осложняется тем, что в нашем городе нет подрядчиков профессионально занимающихся автоматизированными системама управления. Прошу поделиться опытом.

← →
Суслик © (2004-08-25 12:02) [1]

анекет поправь.

← →
Суслик © (2004-08-25 12:02) [2]

Удалено модератором

← →
Игорь Шевченко © (2004-08-25 12:03) [3]

> в каком случае (с какого момента развития) предприятию необходим
> собственный полноценный отдел АСУ, занимающийся постановкой,
> внедрением, программированием и документированием? Или все
> это выгоднее оставить делать подрядчику?

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

← →
Суслик © (2004-08-25 12:06) [4]

Вообще топик скорее всего будет также загноблен как и топики с предолжениями работы.

Имхо не на этот сайт надо...

← →
Nikolay M. © (2004-08-25 12:06) [5]

http://www.sql.ru/forum/actualthread.aspx?tid=117003
Твоя ветка?

← →
Alx2 © (2004-08-25 12:07) [6]

>Nikolay M. © (25.08.04 12:06) [5]
Не моя. Но за линк спасибо :)

← →
KSergey © (2004-08-25 12:23) [7]

Тут вот что еще важно.
Часто получается так: на сротоне есть устраивающий в принципе продукт (к стати, обязательно поискать! хотябы чтобы знать что хотеть), но за него просят ??? баксов.
"Ага, что-то крутовасто. Возьмем ка мы программеров, будем им платить ?/100 баксов в месяц - и они нам сделаю тоже самое"

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

Правда, со сторонним продуктом тоже чехарда: он ведь написан "для всех", а значит часто "ни для кого". На некий усредненный тех. процесс, под которых придется либо перестраиваться, либо мириться, что пользоваться продуктом АСУ будет не так удобно, как хотелось бы.

Свой же отдел АСУ всегда прогнется под существующий тех. процесс, каким бы бредовым и бардачным он ни был. Т.е. тут можно полностью удовлетворить руководство, но не в части улучшения климата на предприятии вообще.

← →
Vovchik_A © (2004-08-25 12:45) [8]

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

← →
Sergey13 © (2004-08-25 12:56) [9]

2Alx2 ©
Расшифруй "полноценный" плиз. Например - что мешает купить ERP систему и писать собственные вордово-екселевые прибамбасы.

← →
Sergey13 © (2004-08-25 12:58) [10]

2[8] Vovchik_A © (25.08.04 12:45)
>Вообще, такие вещи надо планировать с момента основания преприятия
Ну например года с 1920? 8-)

← →
Vovchik_A © (2004-08-25 12:59) [11]

2Sergey13 © (25.08.04 12:58) [10]
ну типа :)

← →
Alx2 © (2004-08-25 13:57) [12]

Sergey13 © (25.08.04 12:56)
>Расшифруй "полноценный" плиз. Например - что мешает купить ERP
>систему и писать собственные вордово-екселевые прибамбасы.

Вот по этой ссылке описывается полноценность:
http://www.u-press.com.ua/sbornic/37-40.htm

Про ERP: Она без настройки от подрядчика и последущее написание "прибабасов" - тот же собственный АСУ получается :)

← →
Alx2 © (2004-08-25 14:09) [13]

>Игорь Шевченко © (25.08.04 12:03)
Вопрос как раз в определении момента :)

← →
Юрий Зотов © (2004-08-25 14:18) [14]

> Alx2

Приходилось мне работать и в отделе АСУ, где мы делали именно специализированный под конкретику продукт. Приходилось работать и в софтверных конторах, где делали то же самое "для всех", а настраивали под конкретику при внедрении у каждого конкретного заказчика. Так вот - судя по моему опыту, взять готовый продукт выходит и дешевле, и быстрее. А какой именно брать продукт - тут уже надо выбирать, это зависит от многих факторов.

Что касается стоимости и сроков - прикиньте сами. Берете общую стоимость стороннего продукта (общая - это значит стоимость самого продукта в нужной Вам конфигурации, плюс стоимость лицензий на дополнительные рабочие места, плюс стоимость услуг по внедрению, адаптации и обучению, плюс... ну в общем, плюс все, что Вам реально нужно). Скажем, у нас эта общая сумма может колебаться примерно от 5 тыс. до 50 тыс. у.е. (в зависимости от требуемой конфигурации, количества и состава рабочих мест, объема дополнительных услуг). ОК, оценка сумммы у Вас есть, теперь узнаете у производителя длительность периода внедрения системы (скажем, у нас он может составлять от 3-х месяцев до года, опять же в зависимости от объема требований заказчика).

Лады, теперь смотрим, во что Вам обойдется собственная разработка. Исходя из моего опыта, для того, чтобы сделать ERP-систему, на которой реально можно работать, требуется, как минимум, пара сильных спецов (с окладом по меркам Москвы где-то в 1500 у.е.), которым потребуется примерно год-два времени (опять же, в зависимости от того, что требуется и при условии, что ничем другим они заниматься не будут). Сразу скажу, что брать более дешевых "спецов" нет смысла - как многократно показывала практика, это будут выброшенные на ветер деньги и впустую потерянное время.

ОК, теперь давайте сравнивать (ориентируясь, например, на средние показатели, потому что конкретные надо и считать конкретно). Итак, если исходить из средних требований заказчика, то, например, за нашу систему (полностью рабочую и настроенную под Вас) Вы платите примерно 25-30 тыс. у.е. и получаете ее примерно через 7-8 месяцев. А разрабатывая такую же систему сами, платите примерно 50-60 тыс. (только одной зарплаты! а сколько всего - прикиньте сами) и получаете ее года через полтора.

Судите сами - что лучше?

P.S.
Если нужны не средние, а конкретные цифры, то можно попросить нескольких потенциальных разработчиков подготовить коммерческие предложения (только обязательно включающие все, что Вам требуется, в том числе и настройку под Вас - иначе Вы получите не цифры, а липу) и сравнить эти предложения между собой. А заодно и сравнить с тем, во что Вам обойдется самостоятельная разработка подобного продукта.

P.P.S.
Давно известно, что разовая разработка конкретного продукта (даже не обязательно софта) под конкретный заказ - штука весьма дорогая. А если это продукт сложный, то еще и весьма нескорая.

← →
Юрий Зотов © (2004-08-25 14:18) [15]

Удалено модератором
Примечание: Дубль

← →
Skyle © (2004-08-25 14:32) [16]

> [15] Юрий Зотов © (25.08.04 14:18)

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

← →
Юрий Зотов © (2004-08-25 14:50) [17]

> Skyle © (25.08.04 14:32) [16]

Если под "периодом" подразумевается длительность собственной разработки, то, видимо так оно и есть (стоимость собственной разработки тем больше, чем она длительнее, а покупка - штука разовая и ее стоимость со временем не меняется).

Если же имется в виду что-то другое, то я не понял, что.

← →
Alx2 © (2004-08-25 14:51) [18]

>Юрий Зотов © (25.08.04 14:18)

Мы тут в историю веселую попали - московские цены при способе написания "на коленке".

У нас подрядчик делал работу по автоматизации бухгалтерии/зарплаты на базе "1С" полтора года. Причем над проектом там работало "в среднем" два человека. В итоге вышло, что свои разработки даже "с нуля" могли быть почти втрое дешевле и, скорее всего, качественнее. И стою вот на распутье: дальше местных "умельцев" выбирать, или все-таки набирать отдел.

PS
или в Elprise обратиться :)

← →
Рамиль © (2004-08-25 14:56) [19]

> а покупка - штука разовая и ее стоимость со временем не
> меняется

Где это разовая. А абонентское сопровождение? Довольно приличные суммы получаются, у нас соизмеримо со всей зарплатой АСУ.

> или в Elprise обратиться :)

В Галактику обратись, и АСУ без дела не останется за одно:)
(Не сочтите за рекламу :о))

← →
Dmitriy O. © (2004-08-25 14:56) [20]

У нас был отдел АСУ при сокращении его снесли в первую очередь.
При том их эффективность была такова то там геде были мало мальские спецы в Акцес и Эксель. То проги писали сами в АСУ не обращались. Я тоже одинар раз заказал там прогу теперь все пишу сам. Вощем заводское АСУ крайне мало эфективно. Лутьше заказывать проги у спец фмрм,

← →
Рамиль © (2004-08-25 14:58) [21]

> [20] Dmitriy O. © (25.08.04 14:56)

Да наслышаны мы уже о твоем АСУ. Если оно у вас такое было, это не значит, что везде так.

← →
Vovchik_A © (2004-08-25 14:59) [22]

2Dmitriy O. © (25.08.04 14:56) [20]

Дадад. Автосхему, например.

← →
Skyle © (2004-08-25 15:10) [23]

> [17] Юрий Зотов © (25.08.04 14:50)

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

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

← →
Сергей Суровцев © (2004-08-25 15:16) [24]

>Юрий Зотов © (25.08.04 14:18) [14]

Все правильно абсолютно. Есть реально несколько моментов,
которые отдел АСУ контролировать, а значит и гарантировать
не может. Это качество разработки, сроки разработки,
квалификацию разработчиков.

Первое - сроки. Поскольку они большие, то и группа
разработчиков может не раз смениться, и требования к продукту.
Так как ТЗ внутреннее, вопрос "как" никого интересовать не
будет.

Второе - найти в отдел АСУ среднего предприятия несколько
спецов уровня грамотного проектирования и написания подобной
системы ничтожен. Такие люди штучны. И в основном уж при деле.

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

Отдельная головная боль - поддержка. Придется лично следить
за законодательством, своевременно внося изменения.

С другой стороны приобретая сторонний продукт предприятие
получает сразу:

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

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

Так что реально работу отдела АСУ я вижу именно в
поддержании и обслуживании профессионально сделаной
и внедренной системы.

P.S.
Лично я ни разу в жизни не видел действительно доведенной
до ума масштабной разработки отдела АСУ. Зато примеры
успешного обслуживания готовой системы видел и немало.

← →
Юрий Зотов © (2004-08-25 15:36) [25]

> Рамиль © (25.08.04 14:56) [19]

> Где это разовая. А абонентское сопровождение? Довольно
> приличные суммы получаются, у нас соизмеримо со всей зарплатой
> АСУ.

Абонентское сопровождение нужно, если Ваши потребности со временем растут (что называется - аппетит приходит во время еды). То есть, Вам требуется какое-то наращивание функционала, не предусмотренное Вами ранее. Вот тогда - да, оно имеет смысл. А если нет - то зачем оно? Ведь ТЗ со всеми Вашими требованиями можно составить уже при заключении первого договора - и тогда Вы сразу получите уже адаптированную под Вас систему.

Мы ведь сравниваем стоимость покупки и самостоятельной разработки, а сопровождение - это уже вопрос второй. Если оно вообще нужно, то ведь и самостоятельно разработанный софт тоже его требует, и его стоимость тоже отнюдь не нулевая.

← →
Sergey13 © (2004-08-25 15:45) [26]

ИМХО.
Можно покупать, можно самим писАть. Но какой-либо успех возможен лишь в одном случае - первое лицо (и ближний круг) хочет этого и знает то чего оно само хочет более-менее конкретно.
У обоих вариантов есть много плюсов и минусов. Но полностью автоматизированного управления производством я не видел и не слышал про такое.

← →
Рамиль © (2004-08-25 16:01) [27]

> [25] Юрий Зотов © (25.08.04 15:36)

А изменение законадательства?

> самостоятельно разработанный софт тоже его требует, и его
> стоимость тоже отнюдь не нулевая.

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

> первое лицо (и ближний круг) хочет этого и знает то чего
> оно само хочет более-менее конкретно.

Да без этого вообще бесполезно внедрять, провалится идея на корню. Будет только бухгалтерия работать...

← →
Юрий Зотов © (2004-08-25 16:13) [28]

> Skyle © (25.08.04 15:10) [23]

> входит ли время на дописывание программы (расширение
> функциональности) во время разработки? Или всё-таки время
> разработки ограничено моментом внедрения?

IMHO, наращивание функционала во время ПЕРВИЧНОЙ разработки не входит. То есть, ПЕРВИЧНАЯ разработка заканчивается моментом подписи акта сдачи-приемки, а далее (если требуется заказчику) заключается отдельный договор на поддержку/сопровождение - вот в ЕГО рамках уже и идут все изменения, которые хочет клиент.

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

Насколько я понял, Вы хотите сравнить для этого случая варианты готового или своего продукта. Тут, IMHO, готовый тоже лучше и вот почему.

Создание ERP-системы, способной работать в быстро меняющихся условиях требует, прежде всего, разработки очень гибкой ее идеологии и очень гибкого ядра - такого, в котором ЗАРАНЕЕ предусмотрена возможность легко менять или наращивать функционал (причем крайне желательно, чтобы для этого не требовалось вообще никаких изменений в самом ядре).

Проектирование систем на ТАКОМ уровне - штука сложная и, говоря всерьез, доступная далеко не всем (причем стоят такие спецы тоже недешево). Ну так вот - для самостоятельной разработки гибкой системы надо: а). найти такого спеца (а еще лучше - двух); б). платить ему (им) соответственно. в). ублажать его (их), что он (они) не уволились раньше времени (иначе деньги пропали зря). г). и т.п.

В то время, как в софтверных командах такие люди УЖЕ имеются и их работа УЖЕ вложена в продукт, который Вы покупаете. Ведь продукт, который сделан "для всех" - он УЖЕ гибкий, по своему определению. Иначе он не смог бы быть "для всех" и фирма давно бы лопнула.

← →
Sergey13 © (2004-08-25 16:27) [29]

2[28] Юрий Зотов © (25.08.04 16:13)
>Ведь продукт, который сделан "для всех" - он УЖЕ гибкий, по своему определению

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

← →
Юрий Зотов © (2004-08-25 16:43) [30]

> Sergey13 © (25.08.04 16:27) [29]

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

2. Речь шла о быстро меняющихся условиях, бизнес-правилах и пр. При таких требованиях продукт просто обязан быть гибким. Вы же сами сказали: "ничего даром не дается" - и это совершенно верно.

← →
Sergey13 © (2004-08-25 16:56) [31]

2[30] Юрий Зотов © (25.08.04 16:43)
>1. Так кто же заставляет Вас покупать именно коробочную прогу?
Под "коробочной" я подразумевал покупную, может и неоправдано. Но поясню. Купил я допустим модуль "зарплата", в которой есть всякие северные доплаты например. А мне они не нужны! Я в Африке работаю. 8-) Но в системе они есть, они обрабатываются (отнимая ресурсы), на их разработку были затрачены ресурсы и вполне оправдано производитель (продавец) берет за это деньги. Но мне это не надо!!! Когда оказывается, что таких "фич" в купленном очень много, поневоле задумаешься, что то что осталось я бы и сам за пару месяцев "слабал". Пусть не гибко, но вот оно мое - что хочу то и ворочу. 8-)

ЗЫ: Это не мои убеждения, это тезис для спора - не интересно не отвечайте. 8-)

← →
Суслик © (2004-08-25 16:59) [32]

> что то что осталось я бы и сам за пару месяцев "слабал"

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

← →
Sergey13 © (2004-08-25 17:01) [33]

2[32] Суслик © (25.08.04 16:59)
Ну замени зарплату с доплатами на склад с партионным учетом. Это пример.

← →
Vovchik_A © (2004-08-25 17:05) [34]

2Sergey13 © (25.08.04 16:56) [31]

Неграмотно организован модуль "Зарплата" тогда, имхо :)

← →
Суслик © (2004-08-25 17:05) [35]

> Sergey13 © (25.08.04 17:01) [33]

не лучше.
хотя смотря, что и как реализовывать.

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

← →
Vovchik_A © (2004-08-25 17:08) [36]

22Sergey13 © (25.08.04 16:56) [31]
Я к тому, что пример неудачный.

← →
Юрий Зотов © (2004-08-25 17:16) [37]

> Sergey13 © (25.08.04 16:56) [31]

> Купил я допустим модуль "зарплата", в которой есть всякие
> северные доплаты например. А мне они не нужны! Я в Африке
> работаю.

Процитирую вопрос, на который я отвечал (см. [23], подчеркивание мое): "случай динамично развивающейся компании, в бизнес-процессах которой постоянно возникают какие-то изменения, отражающиеся на их системе".

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

А БД, видимо, должна оставаться единой для головной конторы и ее представительств?
:о)

← →
blackman © (2004-08-25 17:22) [38]

АСУ нужны, если есть лишние деньги :)

← →
Юрий Зотов © (2004-08-25 17:31) [39]

> blackman © (25.08.04 17:22) [38]

Эх, как бы хотелось завести себе пару-тройку персональных АСУ.
:о)

← →
Vovchik_A © (2004-08-25 17:32) [40]

2blackman © (25.08.04 17:22) [38]
Не надо флейм разводить. :)

← →
Сергей Суровцев © (2004-08-25 17:34) [41]

>Sergey13 © (25.08.04 16:27) [29]
>Покупая коробочную прогу мы на 90% покупаем возможности,
>котые нам никогда не понадобятся. Плюс побочный эффект -
>гарантированное подтормаживание от этой универсальности,
>ибо ничего даром не дается.

Если 90% возможностей вам не нужны, то вы явно покупаете
не то ПО. В любой нормальной ERP-системе есть движек и
есть настройка. Возможности движка обычно универсальны
и необходимы для всех пользователей данного ПО. Настройка
или если хотите надстройка - это специфика вашего
предприятия. При грамотном подходе вы получите как раз
обратный эффект - 90% продукта будет использоваться, а
лишнее просто не будет установлено, а соответственно и
оплачено.
А насчет подтормаживания... Такой эффект может наблюдаться
по двум причинам. Первое - это использование интерпретаторов.
Но за это вы получаете максимальную гибкость настройки,
причем без остановки системы. Второе - при выборе между
скоростью и надежностью в таких системах выбирается
надежность. И это тоже есть правильно. В любом случае
эти потери незначительны и оптимизированны насколько это
возможно. Т.е. при написании подобной системы своими
силами потери будут многократно больше.

Я тут подумал, а почему так? Если строится завод, то
никому в голову не приходит собрать бригаду строителей
для возведения корпусов, собрать бригаду инженеров для
проектирования и создания станков и оборудования и т.д.
Все это нормально заказывается и закупается, монтируется
и внедряется, сдается под ключ и только потом начинается
работа персонала. Ну почему же некоторые думают, что
с ПО что-то кардинально по другому? Что его можно сляпать
своими силами, причем на уровне лучших рыночных образцов?
Не понимаю я этого.

>Sergey13 © (25.08.04 16:56) [31]
>Но поясню. Купил я допустим модуль "зарплата", в которой есть
>всякие северные доплаты например. А мне они не нужны!

Ну купил ты, скажем, BMW. А у него на задних дверцах стекла открываются. А они тебе не нужны, ты же впереди сидишь. Будешь свой автомобиль создавать? За пару месяцев?

← →
blackman © (2004-08-25 18:23) [42]

>Vovchik_A © (25.08.04 17:32) [40]
Это не флейм, а утверждение истины.
Само определение АСУ крайне устарело.
Никакие системы ни чем не управляют и управлять не могут :)
Можно еще согласиться на АИС ... Но и это не нужно :)
Иными словами вам надо с начала разобраться в терминологии, а уж потом ...

← →
Vovchik_A © (2004-08-25 18:37) [43]

2blackman © (25.08.04 18:23) [42]
Ну у нас "Управление информационных технологий" называется. Назвать можно хоть каракатицей. Но служба, подобная АСУ, нужна в любой сфере.

← →
blackman © (2004-08-25 18:45) [44]

Управление информационных технологий не подобно отделу АСУ :)
Отсюда и не понимание того, что в этой службе надо делать.
Посмотрите:
http://yandex.ru/yandsearch?text=%E8%ED%F4%EE%F0%EC%E0%F6%E8%EE%ED%ED%FB%E5+%F2%E5%F5%ED%EE%EB%EE%E3%E8%E8&stype=www

← →
Vovchik_A © (2004-08-25 18:52) [45]

2blackman © (25.08.04 18:45) [44]
Я про каракатицу говорил уже.
Лично мне понятно, что мое управление делать должно. И чего не должно.

← →
Blackman © (2004-08-25 21:56) [46]

>Vovchik_A © (25.08.04 18:52) [45]
Именно про каракатицу я и говорю!
Я привел кучу ссылок и вся эта ерунда сейчас называется информационными технологиями :)
Т.е. под это понятие делается что угодно.
И главное, что начинают сразу с программирования, а не с определения фукций и взаимосвязей. Пытаются привязать готовые программные продукты сделанные совсем для других организаций.
Или еще хуже... Начинают делать только силами программистов без настоящего обследования предприятия.
А ведь главное НЕ программирование! На начальном этапе важнее спроектировать инф. потоки. Правильно спроектировать базу и таблицы. Какие же тут коробочные продукты ? Это возможно только для небольших предприятий с стандартными подразделениями.
Вот и ЮЗ говорит о том, что у них только 2 группы программистов.
А где же аналитики, проектировщики ? Замечу НЕ постановщики задачи, а проектировщики БД!

← →
Skyle © (2004-08-26 06:49) [47]

> [28] Юрий Зотов © (25.08.04 16:13)

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

← →
Юрий Зотов © (2004-08-26 10:03) [48]

> Blackman © (25.08.04 21:56) [46]

> Вот и ЮЗ говорит о том, что у них только 2 группы
> программистов. А где же аналитики, проектировщики ? Замечу НЕ
> постановщики задачи, а проектировщики БД!

Странно Вы читаете, между строк как-то. Да, я говорил о том, что у нас две группы программистов. Но разве я говорил о том, что у нас нет других групп? Это первое.

Второе - почему аналитики, проектировщики, постановщики задач и программисты всенепременно обязаны составлять отдельные группы? Разве что-то мешает аналитикам и проектировщикам, завершив этап анализа и проектирования, тут же превратиться в постановщиков задач и программистов, и САМИМ реализовывать свои же идеи в виде ядра системы? И кто лучше их САМИХ может это сделать?

И третье - неужели Вы полагаете, что продукт, имеющий уже шестилетнюю историю, успешно внедренный и успешно работающий в нескольких десятках предприятий и организаций (причем самых разных по направлению своей деятельности) в самом своем принципе мог быть сляпан "на коленке", без должного проектирования?

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

Странно Вы читаете, между строк как-то. Человек говорит: у нас есть 3 легковые машины (и больше не говорит ничего). А Вы из его слов делаетет вывод, что грузовых машин у них нет и, значит, перевозить грузы они не могут.

Логика - просто супер. Извините, напоминает анекдот про женщину, которая ест селедку.

> Skyle © (26.08.04 06:49) [47]

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

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

А вообще - все зависит от того, что требуется заказчику, поэтому в каждом конкретном случае считать надо. Не так уж это и трудно, сделать хотя бы прикидочную оценку. Либо самому (см., например, [14]), либо пригласить сторонних аналитиков (только не таких, которые с умным видом "ля-ля ни о чем" разводят, а таких, которые действительно способны понять и сказать, а что же Вам нужно).

← →
Sergey13 © (2004-08-26 10:27) [49]

1.Покупная система - это как правило не готовое решение, а набор методов и средств для создания готового решения. И конечный успех сильно зависит от того кто и как это внедряет/сопровождает. Плюс к этому - заказчик попадает в сильную зависимость от поставщика (производителя) ПО, т.е. к независимому от заказчика субъекту.
2.В готовом ПО заложена некая модель производства. Плохая или хорошая - другой вопрос. На предприятии может быть другая модель. Не хуже и не лучше, но другая. Перестройка действующей модели может быть сравнима с полным сносом и строительством нового предприятия. Это кстати одна из основных причин, ИМХО, почему проваливаются многие внедрения готового. Архисложно переделать годами сложившиеся устои. В этом случае проще (я не говорю что просто!!! 8-) создать продукт самим под себя.

← →
Юрий Зотов © (2004-08-26 10:40) [50]

> Sergey13 © (26.08.04 10:27) [49]

> 1.Покупная система - это как правило не готовое решение, а
> набор методов и средств для создания готового решения.

> 2.В готовом ПО заложена некая модель производства.

Не противоречит ли одно утверждение другому?
:о)

← →
Sergey13 © (2004-08-26 10:45) [51]

2[50] Юрий Зотов © (26.08.04 10:40)
ИМХО не противоречит. Покупная система - это как правило не готовое решение, а набор методов и средств для создания готового решения в рамках некой модели производства.

← →
Юрий Зотов © (2004-08-26 10:59) [52]

> Sergey13 © (26.08.04 10:45) [51]

> для создания готового решения

Надеюсь, это просто неудачное сочетание слов, ибо решение может быть ЛИБО готовое, ЛИБО не готовое (то есть то, которое еще надо создавать). А создавать готовое решение не требуется, поскольку оно и без того уже создано.

Ну да ладно, не о том речь. А вот о чем - я полагаю, Вы все же противоречите сами себе. И вот почему.

Если модель (т.е., набор бизнес-правил) УЖЕ принята и УЖЕ реализована в софте, то это и есть решение. О каких же еще других решениях в таком случае вообще может идти речь?

А если речь все же идет о наборе методах и средствах для создания конкретного решения, тот как же можно говорить о том, что модель (т.е., набор бизнес-правил) УЖЕ принята?

Нельзя быть немножко беременной. Либо-либо.

← →
vuk © (2004-08-26 11:06) [53]

to Юрий Зотов © (25.08.04 14:18) [14]:
>Скажем, у нас эта общая сумма может колебаться примерно
>от 5 тыс. до 50 тыс. у.е.
Цифра может колебаться. У нас, еще до начала разработки, приценивались к одной сторонней системе (Кто разработчик - без понятия). Там начальные цифры были в 1.5 - 2 раза выше максимальной для вашей системы. При этом "заточенность" под тонкости бизнес-процесса, неизвестно какая. Тут нужно еще очень неслабо думать, на чем можно потерять больше, на зарплате или на перестройке бизнес-процессов и взаимодействия с клиентами/поставщиками/филиалами, которое иной раз весьма нетривиальное.

>А разрабатывая такую же систему сами, платите примерно
>50-60 тыс. (только одной зарплаты! а сколько всего -
>прикиньте сами) и получаете ее года через полтора.
Это говорит только о том, что сани надо готовить летом. Желательно предыдущим. :o)

to Сергей Суровцев © (25.08.04 15:16) [24]:

>Так как ТЗ внутреннее, вопрос "как" никого интересовать не
>будет.
Если ТЗ внутреннее, то что, программа не должна делать то, что от нее требуется?

>Такие люди штучны. И в основном уж при деле.
Хм... "Кормить надо, тогда и не улетят!" (с) реклама по ящику

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

>Отдельная головная боль - поддержка. Придется лично следить
>за законодательством, своевременно внося изменения.
За законодательством нормальный руководитель следит в любом случае.

>Готовый к работе, отлаженный вариант, запускаемый быстро,
>в котором уже собраны много лет опыта и труда высоко
>квалифицированных разработчиков, оттестированы и отработаны
>все основные блоки.
Я рад за ребят у которых все основные блоки отлажены. Честно. Но дело еще и в том, чтобы это были именно те блоки и именно с той функциональностью, что нужны заказчику. А то частенько ребята с отлаженными блоками действуют по принципу "Мы лучше заказчика знаем, что ему нужно, а заказчик пусть под нас подстраивается как хочет".

>Прелесть в том, что это все можно
>посмотреть в работе еще даже ДО покупки.
Угу, во-во. Посмотрело начальство, прослезилось и решило, что своими силами писать, оно надежнее.

to Сергей Суровцев © (25.08.04 17:34) [41]:
>Настройка или если хотите надстройка - это специфика вашего
>предприятия. При грамотном подходе вы получите как раз
>обратный эффект - 90% продукта будет использоваться, а
>лишнее просто не будет установлено, а соответственно и
>оплачено.
Угу, то есть получается, что 90% функционала таки будет сделано с учетом потребностей заказчика, т.е. под заказ. Что переводит такую систему в разряд заказных. Оставшиеся проценты - это ядро, которое позволяет производителю на основе этого ядра строить разные по функциональности системы. В конце концов ядро может выродиться в какую-нибудь систему Persistent Objects или что-то подобное. Но при написании своими силами задача построения настолько универсального ядра не стоит. Должна быть гибкость, но в пределах существующей модели бизнеса. Если модель радикально меняется, то точно также радикально меняется и информационная система и в обоих случаях необходима переработка.

>Второе - при выборе между
>скоростью и надежностью в таких системах выбирается
>надежность. И это тоже есть правильно. В любом случае
>эти потери незначительны и оптимизированны насколько
>это возможно.
Это конечно так, но до определенных пределов. И чего ж народ так любит ручками в базы 1С лазить? Ах, ну да, тормозит оно.

to Blackman © (25.08.04 21:56) [46]:
>На начальном этапе важнее спроектировать инф. потоки.
>Правильно спроектировать базу и таблицы.
На начальном этапе не информационные потоки надо проектировать, а с требованиями определяться. Базы, это все сильно позже.

to Юрий Зотов:
Юр, вот ты говорил, что для вашей системы некоторые ваши клиенты сами пишут надстройки. Ну и чем это отличается от самостоятельной разработки? Только наличием универсального ядра? :o)

← →
Сергей Суровцев © (2004-08-26 11:15) [54]

>Sergey13 © (26.08.04 10:27) [49]

По п1 - готовое решение - это не просто набор методов.
Это набор универсальных методов, методик и отлаженных
блоков. Насколько полно этими средствами можно решить
проблеммы данного предприятия нужно выяснять (а главное
можно выяснять, т.к. все уже готово) до приобретения
этого ПО. Хорошее готовое ПО позволяет зделать очень
точную настройку на бизнес процессы. Плохое не нужно
брать.
От внедрения всегда зависит все. Какой бы хорошей
не была система, ее можно запросто загубить или настроить
так криво, что без нее проблем будет меньше, чем с ней.
Опять же при покупке нужно ОБЯЗАТЕЛЬНО посмотреть
примеры внедрения на других предприятиях, сравнить,
оценить, внести пожелания, можно даже модель попробовать
создать. Но всегда внедрение будет проходить лучше,
если им занимаются специальные и обученные люди, а не
случайные сотрудники.
Кстати про зависимость. После внедрения от производителя
ПО зависимости практически нет. При хорошей системе
мелкие, даже средние изменения могут вноситься и без
него. Причем есть полная и подробная документация, а
токже консультации самого производителя. А вот
зависимость проекта от нескольких случайных людей,
которые по КЗОТу могут уволиться в течении 2х недель
должна действительно пугать. При этом их творчество
никто проверить не может - они сами по себе. Новые
люди, пришедшие в отдел начнут разбираться заново.
О документации просто молчу.

По п2. Если система не позволяет настроиться на
существующую модель - выкини ее. Правда иногда сама
модель производства нуждается в кардинальных изменениях.
Объективно. В этих случаях в системе (а вернее
поставщиком) будет предложено несколько вариантов
модели, которые по согласовании сторон и станут основой
проекта. ERP-система не имеет права диктовать модель
предприятия, но и сама модель не должна быть нелогичной
и противоречивой. Если автоматизировать бардак,
получится автоматизированный бардак. (с)
И именно для второго пункта архиважно чтобы внедрение
производись профессионально, а не абы как и абы кем.

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

← →
Sergey13 © (2004-08-26 11:25) [55]

2[54] Сергей Суровцев © (26.08.04 11:15)
Приведи, плиз, пример предприятия, где покупная ЕРП система была внедрена полностью и автоматизировала бы все этапы от закупок сырья до сбыта, включая производство. Я не утверждаю, что их нет, но я о них не слышал и мне очень интересно.

← →
Юрий Зотов © (2004-08-26 11:30) [56]

> to Юрий Зотов:

> Юр, вот ты говорил, что для вашей системы некоторые ваши
> клиенты сами пишут надстройки. Ну и чем это отличается от
> самостоятельной разработки? Только наличием универсального
> ядра? :o)

Сроками отличается - раз. Надстройка, в зависимости от нужд клиента, делается от 3 месяцев до года. Создать за такое же время систему такого же уровня "с нуля" - невозможно.

Количеством глюков отличается - два. Поскольку наиболее сложная и ответственная часть (ядро) уже существует, отлажена и прошла многократную и многолетнюю проверку в самых различных условиях.

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

ИМХО, различия весьма существенные.

← →
Сергей Суровцев © (2004-08-26 12:19) [57]

>vuk © (26.08.04 11:06) [53]
>Если ТЗ внутреннее, то что, программа не должна делать
>то, что от нее требуется?

Если ТЗ внутреннее, то требоваться от программы будет
каждый месяц что-то новое. Иногда кардинально. И не
дай вам Бог на этом этапе смены руководства.

>В принципе качество зависит от того, какова квалификация
>разработчика и как поставлен процесс разработки.

Не все предприятия находятся в Москве. И если для каждого
искать по несколько специалистов высокой калификации
понадобятся сотни тысяч, причем в регионах.

>За законодательством нормальный руководитель следит в
>любом случае.

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

>"Мы лучше заказчика знаем, что ему нужно, а заказчик
>пусть под нас подстраивается как хочет".

А врачей, учителей, руководителей таких ты не видел?
Всех их лесом, ищи нормальных.

>Угу, во-во. Посмотрело начальство, прослезилось и решило,
>что своими силами писать, оно надежнее.

Если не секрет, что именно оно смотрело, сколько
и когда. И каковы уже с тех пор успехи "своими силами".

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

Это совсем не одно и то же. Перекрась BMW, смени диски,
обтяни салон кожей и что? Ты сделал автомобиль?

>И чего ж народ так любит ручками в базы 1С лазить?

Про 1С не нужно. Это халтура с самого начала. Хотя даже
в этом случае ее беда не столько ПО, сколько криворукое
внедрение - следствие изначальной дилерской политики
"любому кто попросит". Знаю ребят, делающих очень
неплохо работающие системы на 1С, но это редкость,
и что характерно они-то как раз пальцы не гнут, а слушают
заказчика очень внимательно.

>Ну и чем это отличается от самостоятельной разработки?
>Только наличием универсального ядра?

Я полагаю, что разница примерно та же, что между работой
только на API и работой в Delphi.

>Sergey13 © (26.08.04 11:25) [55]
>Приведи, плиз, пример предприятия, где покупная ЕРП система
>была внедрена полностью

Могу показать и не одно, но это от вас далековато. Лучше Зотова спроси, это поближе будет.

← →
Sergey13 © (2004-08-26 12:31) [58]

2[57] Сергей Суровцев © (26.08.04 12:19)
>Могу показать и не одно, но это от вас далековато.
Я имел в виду ссылки - инет под рукой. 8-)
Я к чему это. На всевозможных около ERPшных сайтах много летает "новостей", что мол "Компания Ля-ля" завершила внедрение модуля "Что-то типа Кадры" из "Супер-пупер ЕРП системы". А вот новостей, что фирма внедрила систему полностью я что то не встречал. "Собираются недрять" полно, а вот "внедрили"... Может не там смотрел. А во всех системах ядра - прелесть.

← →
Skyle © (2004-08-26 12:36) [59]

> [58] Sergey13 © (26.08.04 12:31)

А может компании, которая сама себе систему пишет это всё нафиг не надо?
Она её продавать никому не собирается, так зачем какая-то реклама особенная?

← →
Игорь Шевченко © (2004-08-26 12:40) [60]

Sergey13 © (26.08.04 11:25) [55]

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

На Западе, например, их, как звезд на небе. В любом стоящем учебнике по базам данных описаны :))
Впрочем, google в руки.

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

← →
Alx2 © (2004-08-26 12:50) [61]

>Игорь Шевченко © (26.08.04 12:40) [60]
>И понимают, что готовые решения от специалистов
>в любой области дешевле дилетантских.

Вот-вот. А нам нужно только дилетантов от спецов отличить. И желательно "до того". Не знаю как в Москве, а в Ульяновске народ услышав где-то звон моментально становится "специалистами".

← →
Sergey13 © (2004-08-26 12:50) [62]

2[60] Игорь Шевченко © (26.08.04 12:40)
Запад нам не указ!!! 8-) У них небось и законодательство не так часто и не так кардинально меняется. Ну и другие вкусности - типа капитализм уже развитой, а не в стадии накопления капитала.

← →
Игорь Шевченко © (2004-08-26 13:04) [63]

Sergey13 © (26.08.04 12:50) [62]

> Запад нам не указ!!! 8-)

Ну почему, полезные вещи можно и перенять

← →
Sergey13 © (2004-08-26 13:07) [64]

2[63] Игорь Шевченко © (26.08.04 13:04)
>Ну почему, полезные вещи можно и перенять
Предлагаю последовательность перенятия
1.Законы
2.Правительство
3.Зарплаты
Или с третьего начать? 8-)

← →
Skyle © (2004-08-26 13:08) [65]

> [64] Sergey13 © (26.08.04 13:07)
> 2[63] Игорь Шевченко © (26.08.04 13:04)
> >Ну почему, полезные вещи можно и перенять
> Предлагаю последовательность перенятия
> 1.Законы
> 2.Правительство

А вот это я бы не трогал..

← →
Sergey13 © (2004-08-26 13:09) [66]

2[65] Skyle © (26.08.04 13:08)
Экий ты... избирательный. 8-)

← →
Skyle © (2004-08-26 13:23) [67]

Юрий Зотов © (26.08.04 10:03)
Вот тут http://www.npo-comp.ru/307328.shtml (третий и второй с конца абзац) даются несколько иные цифры, отличные от ваших. Может быть всё не так безоблачно и всё-таки есть случаи, когда имеет смысл потягаться с существующими гибкими и отлаженными ядрами? ;-)

← →
Skyle © (2004-08-26 13:24) [68]

> [66] Sergey13 © (26.08.04 13:09)

Ну дык.. Одно дело - зарплата в вечнозелёных. Вечнозелёные или водоплавающие - меня это, по большому счёту не волнует.
А вот бред, именуемый политикой, я хотел бы видеть поспокойнее...

← →
vuk © (2004-08-26 13:50) [69]

to Юрий Зотов © (26.08.04 11:30) [56]:
>Поскольку наиболее сложная и ответственная часть (ядро) уже
>существует, отлажена и прошла многократную и многолетнюю
>проверку в самых различных условиях.
Берем любой нормальный сервер БД и реализуем логику на нем. Чем не ядро?

>Надстройку делает IT-специалист средней руки и для этого ему не
>нужен никакой лицензионный софт.
Ваша система нужна. Тоже не 3 рубля стоит.

to Сергей Суровцев © (26.08.04 12:19) [57]:
>Если ТЗ внутреннее, то требоваться от программы будет
>каждый месяц что-то новое.
Это далеко не так.

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

>Если не секрет, что именно оно смотрело, сколько
>и когда. И каковы уже с тех пор успехи "своими силами".
Смотрели года три назад какую-то систему, в которой, как говорили "вроде бы все есть". Сколько смотрели и кто разработчик был - не знаю, не присутствовал. Качество категорически не понравилось, сужу по тому как плевались. Просили за систему что-то около 130 тыс. у.е.

С тех пор своими силами за срок около 2 лет написано:
Склад
Производство
Торговля
Сервисное обслуживание
Взаимодействие с поставщиками
Взаимодействие с клиентами
Взаимодействие с филиалами

Все это работает уже с января этого года. Время от начала разработки до запуска - примерно 1.5 года. Сейчас развитие идет. Средства разработки - MS SQL + Delphi.

← →
blackman © (2004-08-26 14:15) [70]

>Юрий Зотов © (26.08.04 10:03) [48]
>Но разве я говорил о том, что у нас нет других групп? Это первое.
Я рад, что есть и другие о которых вы скромно умалчиваете :)

>Разве что-то мешает аналитикам и проектировщикам, завершив этап анализа и проектирования, тут же превратиться в постановщиков задач и программистов, и САМИМ реализовывать свои же идеи в виде ядра системы? И кто лучше их САМИХ может это сделать?
Универсальные солдаты ? Вам не кажется, что один человек не может заниматься всем сразу ?

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

>Благодаря чему ее структура за все эти шесть лет не претерпела никаких изменений, не предвидятся они и в дальнейшем. Поскольку они просто не нужны. Много ли Вы знаете примеров подобного подхода?
Не много.
>Странно Вы читаете, между строк как-то.
>Логика - просто супер. Извините, напоминает анекдот про женщину, которая ест селедку.
Не знаю такого анекдота и не понимаю почему вы все относите на свой счет ? Я совсем не вашу систему имел ввиду. Мало того я не могу говорить о системах которых не знаю, но из тех что я видел очень многие спроектированы на коленке без предварительного анализа. И то, что для такого анализа нужны специально подготовленные люди имеющие достаточно времени это аксиома.
Не понимаю почему вы считаете, что этим должны заниматься те же люди, которые пишут программы. Конечно это возможно, но явно не целесообразно. У программистов свои заботы :)

Хотелось бы добавить, что я НЕ верю в универсальные системы :)
Нет ничего абсолютно универсального. Всегда найдется то, что нужно будет в ней переделать...

>vuk © (26.08.04 11:06) [53]
>На начальном этапе не информационные потоки надо проектировать, а с требованиями определяться. Базы, это все сильно позже
Требования к чему ?
Какие могут быть требования, если не определена инф.база и потоки ?
Не MySql или Oracle, а инф.база - основа проектирования.

← →
vuk © (2004-08-26 14:22) [71]

to blackman © (26.08.04 14:15) [70]:
>Требования к чему ?
Требования к системе. Функционирование каких бизнес-процессов она должна обеспечивать.

← →
blackman © (2004-08-26 15:11) [72]

>vuk © (26.08.04 14:22) [71]
>Функционирование каких бизнес-процессов она должна обеспечивать
Это не требования, а исходные данные. Заявка ...
Например, фраза "Хочу автоматизировать бухгалтерию" :)
Вот и все требования которые вы услышите от заказчика :-)
Возможно там будет еще много слов сказанных от души, но не имеющих практического применения.

← →
Vovchik_A © (2004-08-26 15:12) [73]

2blackman © (26.08.04 15:11) [72]
Мелко мыслите

← →
Игорь Шевченко © (2004-08-26 15:18) [74]

blackman © (26.08.04 15:11) [72]

Лармана читать

← →
Суслик © (2004-08-26 15:31) [75]

Всё объектное проектирование, да объектное.
А как же структурное: idef0, sadt и т.д?

Если мне не изменяет память для первичного недетального проектирования такие технологии считались весьма неплохими. Почему о них никто не споминает.

bpwin для целей выяснения как идут процессы опять же имхо лучше, чем тот же uml. Как мне кажется функциональное проектирование лучше соответсвует словесному описанию, чем объектное: человек (особенно, который говорит хочу бухгалтерию)чаще говорит терминами операций, а не данных. О данных многие понятия не имеют. А вот то, что в конце квартала надо СДАВАТЬ отчетность все знают, а также что нужно ОПРИХОДОВАТЬ ТМЦ и т.д...

Лармана не читал.
Полистал в магазине. Вроде интересная книга. Но опять как мне кажется такое проектирование возможно на детальном уровне. А детальный уровень возможен после анализа...

← →
Суслик © (2004-08-26 15:41) [76]

Кстати, поддерживаю Вука.

У нас также есть зачатки erp системы. Т.е. с возможностью настройки большей части без delphi. Теоретически можно было бы и вообще отказаться от правки ядра. Но как оказалось людей способных профессионально писать на ядре намного меньше, чем людей способных профессионально писать само ядро. О каких спецах-ядровиках за "полтарушку" идет речь? Может и не нужно ядро? Скорее нужен ярких экономист-постановщик, даже не проектировщик заметьте, т.к. проектирование это инженерная специальность и без исходной постановки фиг он что запроектирует. Вот такие постановщики стоят пятачок - экономические знания с таком объеме по доками не найдешь. От таких людей вообще не требуется знание ни ООП ни программирования. Требуется алгоритмичтность мышления, ум, умение вытянуть из неалгоритмичных заказчиков инфу. Закодить обычные люди могут, в том числе и на дельфи + сервер, т.е. без ядра...

← →
blackman © (2004-08-26 15:44) [77]

>Vovchik_A © (26.08.04 15:12) [73]
>Мелко мыслите
Давно и крупно делаю ... :)
>Игорь Шевченко © (26.08.04 15:18) [74]
>Лармана читать
Лучше Пушкина :)
Если бы вы только знали, как много было этих Ларманов...
Но он в чем-то прав:
По мнению автора, многие организации проявляют поразительную недальновидность при распределении ресурсов на различные этапы разработки системы, игнорируя стадии анализа и проектирования и сразу приступая к написанию кода. Очень важную роль в процессе разработки должны играть анализ и проектирование системы. При этом в процессе анализа участникам группы разработчиков следует сосредоточиться на понимании проблемы, а вопросы, связанные с программным решением или производительностью системы, нужно на время отложить.

И

Разработку отдельных уровней можно поручить специализированным группам разработчиков (по принципу уровней и подсистем); при этом поддерживается высокий уровень специализации профессионалов и возможность параллельной разработки всех уровней приложения.

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

← →
blackman © (2004-08-26 15:51) [78]

>Суслик © (26.08.04 15:41) [76]
>Скорее нужен ярких экономист-постановщик,
Очень дорого стоят такие люди, но не все софтверные фирмы их привлекают. Многие пытаются склепать программы без их участия.
Результат работы таких фирм поражает своей бестолковостью...
Очень крутые программы, хорошо оформленные, но ...

> blackman © (26.08.04 15:51) [78]

> Очень дорого стоят такие люди, но не все софтверные фирмы
> их привлекают

конечно дорого - я же сказал пятачок. Знаю, когда больше.

Знаю, что особенно много люди получают именно при настройке известных erp систем (oracle app, r3). Полагаю, что это связано с тем, что:
1) Фирмы иностранные
2) Нет проблем архитектуры - уже все решено.
3) Труд такого человека может быть постребован с большой пользой, т.к. ничего писать не надо, надо понять бизнес-процесс
4) Системы достаточно сложные - мало кто хорошо их знает. Вернее никто кто бы с ними не работал плотно...

> Sergey13 © (26.08.04 12:31) [58]

> А вот новостей, что фирма внедрила систему полностью я что то
> не встречал. "Собираются недрять" полно, а вот "внедрили"...

Вот здесь:
http://www.elprise.ru/ind.php?file=main/company/clients
вы увидите 17 выполненных проектов (то есть, тех, где внедрение уже завершено). В части из них (могу сказать, в каких конкретно, но, честно говоря, лень поднимать документацию) внедрялась именно полная конфигурация. Что это такое, можно посмотреть здесь:
http://www.elprise.ru/ind.php?file=files/documentation/modules

> Alx2 © (26.08.04 12:50) [61]

> А нам нужно только дилетантов от спецов отличить.
> И желательно "до того".

Можно и "до того". Если интересно, могу скинуть на мыло данные нашего ftp, откуда можно скачать Demo-версию (архив около 60 Мб, либо тот же архив в многотомном виде кусками по 2 Мб). Версия эта неполная (ориентирована на торговлю) и с ограниченным сроком лицензии - но, по крайней мере, у Вас будет 3 месяца, чтобы ее посмотреть и решить вопрос о дилетантах/спецах, не потратив ни копейки денег.

> Skyle © (26.08.04 13:23) [67]

> Вот тут http://www.npo-comp.ru/307328.shtml (третий и второй с
> конца абзац) даются несколько иные цифры, отличные от ваших.

Эти цифры - средние по Российскому рынку ERP, а я приводил цифры по конкретному продукту. Не нужно сравнивать. На рынке ходят и такие монстры, что купить их могут, разве что, Газпром, Лукойл и иже с ними.

Если хотите убедится в реальности приведенных мною цифр, можете заглянуть вот сюда:
http://www.elprise.ru/main/price/makefirm.php
и самостоятельно рассчитать стоимость проекта в зависимости от потребностей заказчика (должны быть включены cookies).

> Может быть всё не так безоблачно и всё-таки есть случаи, когда
> имеет смысл потягаться с существующими гибкими и отлаженными
> ядрами? ;-)

Есть такие случаи. Вы, часом, не пропустили в [48] мой ответ на [47]? Там о них и сказано.

> vuk © (26.08.04 13:50) [69]

>> Поскольку наиболее сложная и ответственная часть (ядро) уже
>> существует, отлажена и прошла многократную и многолетнюю
>> проверку в самых различных условиях.

> Берем любой нормальный сервер БД и реализуем логику на нем.
> Чем не ядро?

1. Тем, что оно еще не "прошло многократную и многолетнюю проверку".

2. Тем, что в понятие "ядро системы" я включаю еще и ядро клиентской части - а в твоем примере его вообще нет.

>> Надстройку делает IT-специалист средней руки и для этого ему
>> не нужен никакой лицензионный софт.

> Ваша система нужна. Тоже не 3 рубля стоит.

Стоит она порядка 50 тыс. у.е. (это примерно на 30 рабочих мест, в полной конфигурации и с нашей адаптацией), длительность внедрения будет поряка года). Теперь возьми зарплату (хотя бы только зарплату!) ваших разработчиков, просуммируй и умножь на 24 месяца, в течение которых вы пишете свою систему. Добавь сюда же стоимость MS SQL, Delphi и прочего софта, которым вы пользуетесь. Думаю, в итоге получится, что вы УЖЕ превысили стоимость нашей системы, а написали пока еще только 30% того, что она умеет (сужу по [69]). К тому же, потратив на эти 30% два года (против наших 100% за год).

Ты скажешь - а на фига нам эти 100%, когда нам нужно 30? А я отвечу: ОК, те же самые 30% вы бы тоже могли купить - а тогда и стоимость, и сроки внедрения были бы намного меньше. И снова получится, что это было бы быстрее и выгоднее.

Так о чем спор?

=============================

Леш, пойми, что иначе и быть не может. Наша софтина делается не 2 года, а уже 6 лет, и коллектив разработчиков намного больше, и объем тестирования намного шире, и ни на какие другие дела мы не отвлекаемся. Что могут всему этому противопоставить отделы IT на предприятиях? Им дадут работать 6 лет, большим коллективом и не отвлекая ни на что другое?

Ох, не дадут. По себе знаю.

2Юрий Зотов © (26.08.04 15:55) [80]
>Что могут всему этому противопоставить отделы IT на предприятиях? Им дадут работать 6 лет, большим коллективом и не отвлекая ни на что другое?

Не дадут. Все надо "еще позавчера"

2blackman © (26.08.04 15:44) [77]

Ну неправда Ваша. Заказчики есть - весьма грамотные люди.

> blackman © (26.08.04 14:15) [70]

Пишу:
Разве что-то мешает аналитикам и проектировщикам, завершив этап анализа и проектирования, тут же превратиться в постановщиков задач и программистов, и САМИМ реализовывать свои же идеи в виде ядра системы?

Вы отвечаете:
Универсальные солдаты ? Вам не кажется, что один человек не может заниматься всем сразу ?

Сравните подчеркивания - вот пример того, как Вы читаете посты и как на них отвечаете.

> Ну неправда Ваша. Заказчики есть - весьма грамотные люди.

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

blackman © (26.08.04 15:44) [77]

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

А как иначе ?
Или не знает досконально, а работает в тесном контакте с тем, кто знает.

> Если бы вы только знали, как много было этих Ларманов...

Не так уж и много.

2[80] Юрий Зотов © (26.08.04 15:55)
Спасибо за список клиентов. Вот только преобладают в нем торгово-посреднические предприятия. А с реально сложным (не трудоемким и дорогим, а сложным, типа машиностроение) производством я насчитал пару штук. Интересно например на Мосфундаментстрой-6 производство внедрено? Ведь именно производство представляет нибольшую трудность, ИМХО. Бухгалтерия-склады-расчеты с клиентами все таки достаточно "стандартны" и поддаются сравнительно несложному алгоритмизированию. А вот производство...

идеалисты :(((

опыт моего знакомого, который в бывшей соцстране для одной известной российской бензиновой фирмы ставил изветсную erp говорит, что поставить erp можно только если хозяин очень сильно вставит подчиненным, чтобы они помогали :((( Иначе они саботируют - как это делается с той же фирмой, но у нас.

> Sergey13 © (26.08.04 16:12) [86]

> Вот только преобладают в нем торгово-посреднические
> предприятия.

Я насчитал 8, занимающихся производством. Из 17. Где же "преобладают"? Примерно фифти-фифти.

> А с реально сложным (не трудоемким и дорогим, а сложным, типа
> машиностроение) производством я насчитал пару штук

Что уже следует считать достижением. И реальным подтверждением способности софта работать даже на таких сложных производствах. IMHO.

> Интересно например на Мосфундаментстрой-6 производство
> внедрено?

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

2[89] Юрий Зотов © (26.08.04 16:33)
>Я насчитал 8, занимающихся производством. Из 17. Где же "преобладают"? Примерно фифти-фифти.
Я то судил только по колонке описания фирмы. А там... Впрочем перечитал внимательно, и понял что вы правы - упоминается. 8-)

Меня вообще "Производство" больше интересует, т.к. на прошлой работе (мебельный комбинат) как раз к нему подступался, пока не уволился 8-). В частности
1.межцеховая диспетчеризация
2.обработка извещений об изменении - как обеспечить работу с разными версиями продукции.
У вас это решено? Из описания я не понял.

Sergey13 © (26.08.04 16:52) [90]

Поясните терминологию, плз.

Например, что подразумевается под межцеховой диспетчеризацией?
Если передача полуфабриката из цеха в цех, то это межскладская передача. Если, скажем, синхронизация выпуска комплектующих различными цехами (4 ножки + 1 спинка + 1 сиденье = 1 стул), то это реализовано, как задачи, задания и операции (диаграмма Гантта). А если имеется в виду еще что-то, то что именно?

Аналогично - что значит "разные версии продукции"? Если, например, это разная комплектация (зеленая обивка из материала X, синяя обивка из материала Y и пр.), то такие вещи, конечно, реализованы. Если же подразумевается что-то другое, то что?

> Юрий Зотов © (26.08.04 17:59) [91]

Юрий пользуясь случаем хотел бы спросить вы получали мои письма с вопросами по блоку ОСНОВНЫЕ СРЕДСТВА? (другой возможности спросить к сожалению нет...)

>Юрий Зотов © (26.08.04 16:02) [82]
>Вы отвечаете:
>>Универсальные солдаты ? Вам не кажется, что один человек не может заниматься всем сразу ?
>Сравните подчеркивания - вот пример того, как Вы читаете посты и как на них отвечаете.
Уже спор ? Опять вы о том как я читаю!
Читаю ... Но вы не читаете то, что я пишу, а ждете от меня того, что вам хочется или того, что вам кажется...слышится :-)
НО не надо о грустном :) Давайте по существу:
Согласитесь, что если человек увлечен программированием, ему очень трудно переключиться на проблемы бух.учета даже если он это будет делать поэтапно. Жизнь как зебра полосатая ? :)

>Vovchik_A © (26.08.04 16:02) [81]
>Ну неправда Ваша. Заказчики есть - весьма грамотные люди.
Большая редкость, но бывают. Однако ориентироваться надо не на них, а на большинство. Конечно если вы хотите множества продаж вашей системы, а не делаете ее для уникальных грамотных :-)

>Юрий Зотов © (26.08.04 15:55)
Почта - в анкете. Alx@argo.mv.ru

Специфика у нас, правда, не торговая. Однако интересно посмотреть. Авось, поженимся :)

[80] Юрий Зотов © (26.08.04 15:55)

Читал.

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

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

Что могут всему этому противопоставить отделы IT на предприятиях?

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

На счеет эконимической целесообразности АСУ как средства для разработки и поддержания ПО. В среднем выходит написать ПО силами АСУ дороже или соизмеримео с заказаом ПО на стороне а качество ПО на порядок ниже. И это обьективно и везде.

> Skyle © (27.08.04 06:44) [95]

> Сложно согласиться, поэтому и спрашивал.

Может, и сложно. Но нужны конкретные аргументы. Еще лучше - конкретные факты и цифры. Как в [69], например.

> Но я имел ввиду систему с нормальными, не урезанными
> требованиями, обладающей набором функциональности, похожей на
> вашу

Еще раз - наша делается уже 6 лет. Коллектив разработчиков в разное время составлял от 5 до 15 человек (и они не занимались ничем другим, причем несколько человек в этом коллективе - это высококлассные спецы). Объем тестирования - более полутысячи рабочих мест, ежедневно, по 8 часов, в течение нескольких лет.

Какой IT-отдел может себе такое позволить и чтобы его при этом не разогнали через год-другой? Если такой есть, то да, он может сделать такую же систему. Если же такого нет - то о чем вообще говорить?

> которую вы усиленно рекламируете (очень часто приводите в
> качестве примера).

Блин, так и знал. Вот меньше всего хотел, чтобы это было принято за рекламу. Разве непонятно, что я привожу просто-напросто те примеры, которые хорошо знаю? Ну откуда, например, я могу знать, как рассчитывает стоимость своих систем Парус, или Галактика, или еще кто-то? Дают ли они Demo-версии? Внедряли ли они где-нибудь свои системы в полном объеме, или нет? Сколько это занимало времени? Ну откуда я могу все это знать?

А про нашу - знаю, вот поэтому о ней и говорю.

> [97] Юрий Зотов © (27.08.04 07:39)

Существует система, такая же, как в [69], только без производства. Инструменты - те же, срок разработки до внедрения - аналогичный. Работает 4 года. В команде есть разработчики высокой квалификации.
Плюс неизбежная интеграция с зоопарком специализированных систем.

Стоимость не знаю, с моего места этого не видно.

Тестируется на полутора тысячах рабочих мест, 8-24 часов в сутки, минимум 5 дней в неделю.

> Блин, так и знал.
Чтобы меня не обвинили в антирекламном заявлении я сделал уточнение. Жаль, что не достиг цели.

2[91] Юрий Зотов © (26.08.04 17:59)
Про диспетчеризацию - я имел в виду второе.

>что значит "разные версии продукции"? Если, например, это разная комплектация (зеленая обивка из материала X, синяя обивка из материала Y и пр.), то такие вещи, конечно, реализованы. Если же подразумевается что-то другое, то что?
Подразумевается следующее. Есть сложное изделие из сотен взаимосвязанных деталей. На каком то этапе конструктор решает внести изменение в конструкцию какого то узла (подмножества взаимосвязанных деталей). Естественно, что "старые" детали не соберутся с "новыми". Да и стоят они по разному и техпроцесс (даже маршрут) у них может измениться. Но в производстве уже есть задел "старых" деталей - у некоторых на 10 конечных изделий, у некоторых на 100. Вот и проблема как все это совместить с выходом на межцеховую диспетчеризацию. Проблема усложняется наличием вариантов техпроцесса, когда существует несколько равноправных техпроцессов и выбор конкретного зависит от загрузки оборудования и многих других причин.
Мы это собирались решать (не успели - завод развалился 8-) через создание некоего архивного (ридонли) "комплекта документации" представляющего некое согласованное состояние информации.

> Объем тестирования - более полутысячи рабочих мест, ежедневно,
> по 8 часов, в течение нескольких лет.

пользователь не тестер
имхо
пользователь это пользователь
тестер это тестер

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

> Суслик © (27.08.04 10:42) [100]

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

> paul_k © (27.08.04 11:15) [101]

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

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

> [102] Суслик © (27.08.04 11:38)

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

> Alx2 © (26.08.04 22:13) [94]

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

> Skyle © (27.08.04 08:06) [98]

> Существует система, такая же, как в [69], только без
> производства. Инструменты - те же, срок разработки до
> внедрения - аналогичный. Работает 4 года. В команде есть
> разработчики высокой квалификации.

> Стоимость не знаю, с моего места этого не видно.

То есть, имеем примерный аналог [69]. Значит, и ответ мой будет примерно таким же - см. [80]. В том числе, и по стоимости - думаю, только одна зарплата пары разработчиков высокой квалификации за весь срок разработки уже оказалась сравнима со стоимостью покупной системы (не считая зарплаты остальных, стоимости софта и прочих расходов фирмы на содержание разработчиков). В итоге же срок разработки и внедрения составил пару лет, а возможности системы оказались существенно ниже, чем у покупной. И если теперь Вы будете эти возможности наращивать, то, соответственно, на это уйдет время, а система выйдет еще дороже.

Короче говоря, чтобы примерно равные по силам коллективы смогли сделать примерно равные продукты им, очевидно, потребуется и примерно равное время. Значит, на разработку системы, примерно такой же, как наша, у Вас тоже уйдет лет шесть. Прикиньте на калькуляторе, во что это обойдется Вашей конторе, если не за шесть, а за ДВА года только одна зарплата УЖЕ оказалась сравнимой со стоимостью покупной системы (или даже превысила ее). И срок - шесть лет, а мог бы быть год.

Вот и судите сами.

> Sergey13 © (27.08.04 09:32) [99]

Это не совсем моя епархия (моя - ядро ядра, если можно так выразиться), поэтому уточню у прикладников и постараюсь ответить.

← →
Мюмзик в мове (2004-08-27 13:18) [106]

Быстрое внедрение - это еще не все!
Ну хорошо, внедрили систему, 5 лет работает прекрасно.
Понадобилось изменить что-то принципиальное и все, приехали:
поддержки уже может не быть, данный продукт уже не разрабатываеся, предлагается новый аналог уже по соответствующей цене.
Наблюдал лично сам, из-за мелочи запросили несколько тысяч, решили сами разработать, пока обходится дешевле.

2[105] Юрий Зотов © (27.08.04 13:13)
>поэтому уточню у прикладников и постараюсь ответить.
Если не очень обременительно, то с удовольствием послушал бы. Теперь это из чистого любопытсва уже, а в свое время весь инет перерыл на эту тему - никаких зацепок. Поэтому с мучениями изобретал свой велосипед.

Какой-то неполный анализ.
Зотов конечно прав - надо делать прикидки по деньгам.
Но не все так просто.
В пользу самостоятельной разработки:
+ получаете полную дальнейшую свободу для модификаций, сапорта (при грамотном написании)
+ тиражируете ПО сколько угодно
+ поднимаете уровень специалистов - в будущем дешевле обойдуться разработки

Вот тут почему-то говорят только о крупных единичных ПО для заказчика. А если вам нужно дешевое коробочное ПО (ну баксов 400-1000 за копию) в колл. 50 копий. 50*~600=30 000$
А если данное коробочное ПО вас немного не устраивает а другого нету, разработчик за океаном, разовыми заказами не занимается, исходники не дает - что делать?
Причем ПО по сути несложное, просто неизвестные, новые технологии, тираж небольшой, потому и цена относительно большая. Это не ВинХП за 99 баксов и тиражом в сотни миллионов.

---
Я просто хочу показать другие факторы...

Исходим из того, что

стоимость непосредственно разработки одинакова в софтверной компании и в IT-отделе

Дальше смотрим: у софтверной компании к этому плюсуюется себестоимость продаж (часто немаленькая), расходы на руководство и она должна получать прибыль (желательно большую). Но софтверная компания тиражирует продукт, поэтому функционал, который находится в коробке, будет дешевле.
Теперь берем функционал, которого в коробке нет. Его можно написать самим, можно заказать. И вот эта доработка не может быть дешевле, чем самостоятельная. Реально помножьте свои расходы (оптимистично) на 2.5
Теперь возьмите доступный Вам коробочный продукт, оцените, сколько Вам надо дорабатывать, и получите ответ на свой вопрос. Учитывайте также расходы на администрирование, которые являются пожизненными, а не разовыми, и немаленькими.

> Юрий Зотов ©
> Разве что-то мешает аналитикам и проектировщикам, завершив
> этап анализа и проектирования, тут же превратиться в
> постановщиков задач и программистов, и САМИМ реализовывать
> свои же идеи в виде ядра системы? И кто лучше их САМИХ может
> это сделать?
Проектировщики в постановщиков превратиться могут. Но в программистов - врядли. Как правило, такие люди к кодированию относятся с большой грустью. То есть они могут немного пописать, поразбираться, но только для проверки каких-то своих идей или суперответственные вещи (небольшие по объему)

> Игорь Шевченко ©
> На Западе, например, их, <полностью внедренных EPR Petr V. Abramov > как звезд на небе. В любом стоящем
> учебнике по базам данных описаны :))
По западной же статистике, неудачных внедрений - 40%. О неудачных внедрениях все молчат - это никому не надо афишировать, в первую очередь - top-менеждменту, выкинувшему на ветер милиионы $

Когда предприятию необходим собственный полноценный отдел АСУ? Найти похожие ветки