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

← →
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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И

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

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

>Суслик © (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 лет, большим коллективом и не отвлекая ни на что другое?

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

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