Dried Gagarin guest_20040621Конфигурирование предполагает правила, которые сами по себе ниоткуда не возьмутся.
Вот именно. Теперь давайте оценим трудоёмкость "извлечения правил" из тупого клиента и сравним с затратами на кодирование и тестирование. Первый пункт гораздо более трудоёмкий.
А теперь давайте заменим последний пункт не кодированием и тестированием, а настройкой системы самим пользователем и сравним трудоёмкость. Мне кажется, что кодирование сторонней или внутренней организацией/структурой более дорогой, нежели донастройка системы "обычным" пользователем.

sleshiy Dried GagarinСвятого грааля в виде самоконфигурирующейся системы мне никто не предложил, к сожалению.
И вряд ли предложит. Во всяком случае в ближайшую пятилетку.
guest_20040621Очень плохо. Работа - это не религия. Когда тупые заказчика начнут это осознавать, Вы потеряете свой источник дохода.
Я думаю, что когда заказчик научится осознавать, что любая система может и должна развиваться, он сам будет искать специалиста. Если заказчик будет самостоятельно развивать систему, а не свой бизнес, то ему стоит переквалифицироваться. Вспомните профессора Преображенского (дабы не развивать эту мысль). Платить все равно придется. Или специалисту, или своим временем. А в бизнесе время и связанные с ним нереализованные бизнес-планы могут создать несоизмеримо большие потери, чем затраты на поддержку и развитие системы. Поэтому осознание этого заказчиком скорее гарантирует доход узкопрофильному специалисту.
Не стоит путать тёплое с пушистым. В любой фирме есть ИТ отдел, который "заведует" состоянием различных систем, и, как ни странно, конфигурирует их под новые нужды. И, по хорошему, этот же отдел должен заниматься конфигурированием системы. Зачем же платить в сторону?

sleshiy Ващенков АлексейМне кажется, что кодирование сторонней или внутренней организацией/структурой более дорогой, нежели донастройка системы "обычным" пользователем.
Не уверен, что "обычный" пользователь освоит систему на том же уровне, что и ее создатель или специалист, который этим живет. При сопоставлении "специалисту заплатил" и "сделал сам и все бесплатно" создает весьма условную выгоду в пользу второго варианта.
Если этот "пользователь" понимает бизнес-процессы предприятия, то настройка системы, допустим изменение/создание бизнес процесса через пользовательский интерфейс, проблем у него не вызовет и зайёмёт минимум времени.
А вот тоже действо через кодирование займёт намного больше времени, и отнимет больше денег.

sleshiy Ващенков АлексейЕсли этот "пользователь" понимает бизнес-процессы предприятия, то настройка системы, допустим изменение/создание бизнес процесса через пользовательский интерфейс, проблем у него не вызовет и зайёмёт минимум времени.
А вот тоже действо через кодирование займёт намного больше времени, и отнимет больше денег.
А Вы считаете, что тот, кто создавал тот же пользовательский интерфейс, должен палец сосать.
Тот кто создал этот интерфейс заинтересован в новых клиентах, а не растрата своих ресурсов на "мелкие" дороботки.
sleshiyЕго заинтересованность в совершенствовании технологий напрямую связана с возможностью своего заработка. Поэтому и возникает необходимость кодирования.
Совершенствование технологий - это одно (новая ВЕРСИЯ программы), подсадить клиента "на иглу" - совсем другое (когда он не может без написание этого кода расширить функциональность в определённых рамках)

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

автор=sleshiyВы, по-моему, сами себя уже запутали. То нужно, то не нужно.
Я ничего не напутал. Внедрение программного комплекса подразумевает, что в рамках договора выполнены все работы в определённый срок, и пользователь получает полнофункциональную систему без необходимости её постоянного дописывания, как только у пользователя произошли минимальные изменения, внутри уже существующего бизнеса (типа: изменение бизнес-процессов, изменение алгоритма расчёта себестоимости, настройки нового отчёта или же открытие новых филиалов или нового направления бизнеса с аналогичными задачами). Именно это можно назвать грамотным внедрением, когда заказчик получает комплекс, способный гибко настраиваться силами заказчика, без привлечения однопланового (специализирующегося на поддержке одного продукта) специалиста.
А вот если фирма занималась носков, и вдруг "завела" производство автомашин "на стороне", и хочет для автоматизации производства использовать тот же программный комплекс, то тут без доработки, в общем случае, не обойтись.
На этом думаю вопрос доработок и настроек считаю закрытым.

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

С моей точки зрения именно это и можно назвать правильным внедрением и ведением проекта

Сергей Васкецов Ващенков АлексейЯ думаю изменение законодательства не регламентирует внутреннее устройство ПО. Скорее оно регулирует некоторый "набор" документов и процедур, для правомерной деятельности предприятий. Набор документов, в соответствии с изменением законодательства нормальный производитель ПО должен рассылать автоматически и бесплатно.
Давайте на примере. Ввели амортизационную премию (58-ФЗ). Ни один печатный документ не изменился. Алгоритм работы софта изменился. Кто что кому должен бесплатно "довнедрить"?
В данном случае в системе есть некая процедура, расчёта амортизации. Если система внедрена таким образом, чтобы гибко влиять на изменения. То данный алгоритм зашит не в самой программе, а в неком "настроечном" файле (как макрос в екселе), который можно изменить не прибегая к изменению внутреннего устройства работы ПО. Для того чтобы изменить макрос расчёта амортизации не надо звать разработчика, или специалиста, который знает как работает ПО внутри. Обычно с такими задачами справляются люди уровня сис.админа при наличии документации или услуги тех.поддержки.

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

На счёт того, что такое амортизационная премия, тут вы правы - я не ознакомился с этим понятием до написания ответа, в чём был не прав. Но суть не в этом. Сейчас я ознакомился с понятием амортизационная премия. В данном случае для конкретного "объекта" основных средств указывается размер амортизационной премии, котрая, автоматически будет занесёна в статью расходов за отчётный период.

al1618...Все выше перечисленные подходы влияют на изменение отношений на рынке.
ИМХО - внедрение ЕРП системы это не "купля-продажа" где каждый стараться "урвать" себе "будущую выгоду". Внедрение - это стратегическое партнерство на длительный период и от степени доверия между Разработчиком/Интегратором/Заказчиком успешность зависит в первую очередь. А вместо доверия получаем противостояние еще на стадии тендера-договора, та потом дальше и идет.
А все новомодные методы "управления проектом" и "критериями успешности". Дают только "успешный по документам" проект. Когда все подписано, все внедрено в соответствии с документами, но еще до завершения понятно что "закрыть потребности" не вышло и Заказчик начинает поиски новой системы, еще толком не начав пользоваться предыдущей.
Очень тяжело читать, я ничего не могу сказать ни за, ни против. Хорошее внедрение и должно так заканчиваться, как вы описываете. Но надо понимать, что такое внедрение возможно, скорее всего, только в сотрудничестве с крупной компанией. Которой выгодно искать новых клиентов, а не заниматься разбрасываться ресурсами, на доработку уже "завершённых" проектов.
Встаёт встречный вопрос, почему же заказчики выбирают именно этот вариант развития событий, а не сотрудничество с "большой" фирмой?
Скорее всего - просто скупость, либо неверная оценка рынка. Когда маленькая фирма говорит, что мы сделаем это вам за 10000 у.е., а крупная говорит за 30000 у.е. Только крупная завершит проект и оставит клиента на тех.поддержке (в том смысле, что отслеживание изменений в законодательстве бесплатно , разрешение различных вопросов опять же бесплатно в рамках тех поддержки ) за скромную сумму в 100-200 у.е в месяц, по желанию заказчика. В то время как мелкая будет ещё полгода "дорабатывать" проект за 3000-5000 у.е. в месяц.

Сергей Васкецов Ващенков АлексейВ данном случае для конкретного "объекта" основных средств указывается размер амортизационной премии, котрая, автоматически будет занесёна в статью расходов за отчётный период.
О чем и речь. Фактически, делаем ручные проводки в НУ. В таком виде, безусловно, нет вообще никакой необходимости вносить изменения в ПО. Достаточно сделать журнал ручных проводок.
Ручные не ручные. Вы для каждого объекта указываете, как вы его будете учитывать. При помощи настроек можно сделать таким образом, что часть ОФ (по определённым признакам) будет использовать одну схему списания, другая другую. Это тоже можно сделать при помощи настроек и тех же фильтров. Вопрос в определении этих признаков - а макрос, вопрос 10-20 минут.

Ващенков АлексейЭто тоже можно сделать при помощи настроек и тех же фильтров.
Ошибка фильтров = макросов

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