iscrafm
я не говорю об искре и о паре месяцев, для этого нужны более конкретные вводные. Возьмите систему, разложите все "по полочкам" на необходимые формы, процедуры БЛ, расчеты, отчеты и т.п. Посчитайте, какие трудозатраты займет реализация каждого блока и отнимите от этого время, которое не нужно тратить на создание инфраструктуры системы, рисование форм, связывание модулей, программирование интерфейса...Останется БЛ.
разложить по полочкам и займет не менее 50-70% бюджета.
еще много времени и денег уйдет на тестирование, написание документации и т.п.
а на само по себе "создание инфраструктуры системы, рисование форм, связывание модулей, программирование интерфейса" уйдет скорее всего не более 10-15% бюджета
так что говорить, что стоимость создания ерп платформеннозависима - нельзя. то есть она зависит, но достаточно слабо - на уровне нескольких процентов

HoBTID
В своем первом очень успешном внедрении, я поменял наполовину план счетов бух. учета в типовой бухгалтерии 7.7, а именно изменил субконто и субсчета на всех основных счетах (01, 02, 04, 05, 08, 10, 19, 26, 41, 42, 44, 57, 60, 62, 68, 76, 90, 91, 99).
Переписал модули проведения почти всех документов, в том числе, все алгоритмы расчета себестоимости, все алгоритмы работы с ОС и НМА, а также все алгоритмы списания косвенных издержек. Полностью переделал формы половины документов.
Написал свою загрузку из складской базы данных.
Все вместе заняло 6 месяцев работы.
В результате, сильно упростилась работа бухгалтеров, данные в базе стали содержать намного меньше ошибок, в разы увеличилась скорость проведения документов.

Это действительно очень хороший результат. К сожалению, достаточно редко при внедрениях думают об упрощении работы.
Но представьте, что предприятию нужна не просто учетная система, а ерп:
очень простое небольшое производство, склад (с ячейками и т.п.) и с автоматизированным поддержанием уровня запасов в региональных складах, закупки, продажи (с наворотами с ценами - скидки с условиями) и бухгалтерия. То есть у предприятия есть потребность планировать потребление, под это потребление закупать или производить товары (для производимых закупать сырье), контролировать взаиморасчеты с контрагентами (не превышать лимиты отпуска в долг, контролировать, что платежи проходят вовремя) и т.п. Количество сотрудников - до сотни, и большая часть должна работать в системе...
То есть достаточно типичные потребности фирмы, которая превращается из мелкой в среднюю (начали как чисто торговая, а сейчас решили и производством немного занятся).
Объем работ будет примерно в 7-10 раз больше. то есть один человек сделает за 3,5-5 лет. столько ждать никто не согласится. значит нужна команда. причем один главный - продумает в общих чертах, как все работает (архитектор), и распределит кто что делает (ПМ), нужен будет тестировщик, который будет проверять как работает все вместе, и т.д. - проект займет минимум год (время на изучение потребностей, продумывание общей схемы работы и всякие согласования) и над проектом будет работать команда из 6-9 человек. И хорошие шансы на успех есть только в том случае, если руководит этим всем специалист, достаточно хорошо разбирающийся и в бизнесе, и в программировании и архитектуре ИС и при этом неплохой руководитель проектов. То есть руководство фирмы сперва должно найти такого специалиста (а ведь фирма к разработке ПО отношения не имеет, и найти КВАЛИФИЦИРОВАННОГО специалиста им трудно), потом он должен найти рядовых спецов и выполнить всю работу...

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

самое смешное, что примерно так у многих фирм и происходит / происходило.

iscrafm

p.s. От Ваших стереотипов по поводу того, как создаются системы просто в глазах рябит . Извините, что немного с сарказмом, но я за нераспространение подобного публично. Лучше когда люди занимаются своим делом: консультанты - консультируют, разработчики - разрабатывают. Когда консультант начинает рассуждать о разработке, получается такая ерунда, что не поправить просто невозможно.
Я достаточно хорошо знаю, что такое сбор требований и постановка задачи. И сколько на это уходит времени.
Я одно время работал в фирме, которая занималась разработкой софта на заказ (не разработчиком, маркетологом). И общался с ребятами, которые разрабатывали одну систему (они работали втроем). Кстати, далеко не такую сложную, как ерп. И у них минимум 70% времени уходило не на само по себе кодирование, а на всякие сопутствующие задачи - вроде выяснения - а что надо делать в такой ситуации, и т.п. Или вы знаете заказчиков, которые сразу могут предоставить качественно проработанное и непротиворечивое ТЗ? или по вашему мнению написание ТЗ не входит в проект? вы никогда не сталкивались с ситуацией, когда никто не может внятно объяснить, как должна выполняться какая-либо задача? например, на складе бардак. очень сильное желание навести порядок. надеются, что с помощью системы смогут навести порядок (и руководство ГОТОВО прилагать большие усилия по наведению порядка). но как именно все должно быть - никто точно не знает. конечно, можно сказать, что это задача не разработчика. но при разработке ерп системы своими силами именно это будет встречаться на каждом шагу.
и как тут поможет платформа?

iscrafm
s_ustinovИли вы знаете заказчиков, которые сразу могут предоставить качественно проработанное и непротиворечивое ТЗ? или по вашему мнению написание ТЗ не входит в проект? вы никогда не сталкивались с ситуацией, когда никто не может внятно объяснить, как должна выполняться какая-либо задача?
а специалист, создающий систему на что тогда? Я лично, кстати, сторонник итеративных моделей разработки. Сразу, качественно проработанное и непротиворечивое ТЗ никогда не требую, если сам делаю проект. У нас с вами, судя по всему, слишком разные взгляды на информационные системы. Два мира, два детства. Можно конечно полгода ходить за заказчиком и требовать полное ТЗ, можно как в первый раз на каждом проекте выяснять как считается себестоимость, можно посадить десяток кодеров на реализацию и т.п. Но есть и альтернативы.

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

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

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

iscrafm
s_ustinovнапример, на складе бардак. очень сильное желание навести порядок. надеются, что с помощью системы смогут навести порядок (и руководство ГОТОВО прилагать большие усилия по наведению порядка). но как именно все должно быть - никто точно не знает. конечно, можно сказать, что это задача не разработчика. но при разработке ерп системы своими силами именно это будет встречаться на каждом шагу.
и как тут поможет платформа?
Зачем эти фантазии. Какая-то какофония: никто ничего не знает, но почему-то собираются разрабатывать ERP. Самому должно быть смешно. Если все же это было сказано не в шутку, тогда грустно. А платформа помогает в реализации, а не в постановке задачи. Найдите нормального постановщика, который знает как решаются различные задачи и понимает, что хочет получить заказчик.
Этот аргумент как раз и использовался для того, чтобы объяснить, почему обычной средней фирме не стоит заниматься самостоятельно разработкой ерп систем. и кстати я знаю несколько случаев, когда именно так и было - начинали разработку без точного знания, что и как. у некоторых, кстати, получалось получить работающее решение. но времени и сил это занимало довольно много (моя оценка в год еще очень оптимистичная).
а вот случаев, когда фирма начинала разработку, точно зная, что и как должно быть сделано, я не знаю - ведь они специализируются на торговле, производстве, строительстве, но никак не на разработке ПО. то есть у них в штате нет бизнес консультантов, которые хорошо разбираются в бизнес процессах, у них нет постановщиков, которые могут собрать требования и выработать ТЗ, нет разработчиков, тестировщиков и т.д.
можно нанять.
и получим примерно тот объем работ, который я указал (и я исходил из оптимистичных оценок)

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

Егоров Александрs_ustinovнапример, на складе бардак. очень сильное желание навести порядок. надеются, что с помощью системы смогут навести порядок (и руководство ГОТОВО прилагать большие усилия по наведению порядка). но как именно все должно быть - никто точно не знает
Это значит, что на таком предприятии будет очередное "провальное внедрение ERP" :). Ибо само по себе внедрение ERP проблему "никто точно не знает" не решить. Если руководство само не понимает "как именно все должно быть" - как узнать, насколько подходит это "должно быть", реализованное в конкретной системе? На таких предприятиях как раз и расцветают переделки типовых решений. Когда систему купили, и вроде как внедрили, но работать стало еще хуже, потому что получилось, что предложенное "как именно все должно быть" - оказалось совсем другим порядком, навести который так сильно желало руководство. :)
вовсе нет
я не даром выделил, что руководство ГОТОВО прилагать большие усилия :-)))
и в большинстве случаев им подходит стандартный функционал с небольшими доработками.
то есть ты им говоришь - можно сделать так и так (описываешь стандартный функционал)
они отвечают - ну в целом такой вариант нам подходит
разумеется, потом скорее всего будут некоторые доработки, но они основные вещи не затронут

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

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

Согласен.
но мы ведь говорили не о внедрении, а о разработке. :-)))

разработали сначала бухгалтерию. и единицы измерения для каждого товара выбирали из списка (как в 1с бухгалтерии)
потом начали разрабатывать склад... и поняли, что не годится - сделали отдельный справочник и ПЕРЕПИСАЛИ довольно много кода. например, количественные движения - надо везде добавить преобразования в базовую единицу или везде хранить и единицу измерения и пересчитывать остатки из разных (второй вариант намного сложнее, но где то может именно так и надо)
потом обнаружили, что правильнее для склада ввести отдельные виды документов - то есть реализация - для финансового учета, а складские ордера - для складского - опять переписали и начали разработку продаж и закупок..
и тут выяснили неприятную вещь - иногда в системе есть товар, а на складе нет (потеряли, украли, не нашли, бракованный) и выписанная реализация содержит больше товара, чем фактически выдано (то есть сперва оформили продажу, а когда клиент пришел на склад, ему не все выдали)...
по быстренькому добавили проверку количества и автоматом переделываем реализацию на правильное количество...
тут владелец намекает - нельзя так
если сотрудники могут переделывать проведенные документы - они ведь сперва все оформят как было, а потом "немножко" увеличат скидки - а разницу себе...
напрягаемся... переделываем много-много всего...
и когда все уже сделано и начинается работа - главбух устраивает скандал - вы что себе ля-ля-ля редиски удумали? да как я проверке из налоговой покажу такой учет - у меня за неделю больше 100 корректировок получается! да они же мне жить спокойно не дадут - день и ночь проверять будут! как хотите, но сделайте как раньше - чтобы учет был чистым и красивым, без этих ваших дурацких корректировок!
и тут вы понимаете - вот и пришел в гости белый и пушистый северный зверек... ;-)))

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

Егоров Александр
А откуда они узнают, стандартный функционал какой именно системы ? :)
при выборе желательно рассмотреть НЕСКОЛЬКО вариантов и выбрать самый подходящий.
Естественно, если выбор делает начальник ИТ отдела исключительно по принципу "где откат больше" выбрать лучшую не получится :-)))
но таким фирмам еще РАНО внедрять ерп систему ;-)))
любую. почти наверняка то НСИ не получится унифицировать, то еще какие "объективные" трудности возникнут :-)))