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

← →
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-системы, способной работать в быстро меняющихся условиях требует, прежде всего, разработки очень гибкой ее идеологии и очень гибкого ядра - такого, в котором ЗАРАНЕЕ предусмотрена возможность легко менять или наращивать функционал (причем крайне желательно, чтобы для этого не требовалось вообще никаких изменений в самом ядре).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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