Консалтингу не выгодна разработка

[fed]

Я ни разу не видел внедренного стандарта (пусть даже с минимальными модификациями типа интеграции с внешним ПО типа клиент-банка). Просто если этот стандарт расширять, а не переписывать (чем обычно партнеры и занимаются), то можно внедрить малой кровью, с разумными затратами на разработку/отладку/поддержку. Проблема в том, что этот стандарт мало кто понимает, соответственно - в 90% случаев (кстати и за пределами России тоже), разработка сводиться к тому чтобы переписать весь функционал, который консультанты не поняли или не смогли объяснить клиенту...
Вопрос то не в том чтобы внедрить без дописывания, а в том чтобы найти оптимум между дописыванием и изменением бизнес-процессов клиента (что тоже вообще-то большие затраты и риски несет).

[Pustik]

Цитата:

Сообщение от fed

Просто если этот стандарт расширять, а не переписывать (чем обычно партнеры и занимаются)

Золотые слова

[Мартынов Дмитрий]

Цитата:

Сообщение от Pustik

Золотые слова

Ну в этом вопросе у нас тут консенсус.

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

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

[fed]

Цитата:

Сообщение от Мартынов Дмитрий

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

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

[Мартынов Дмитрий]

Цитата:

Сообщение от fed

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

Не надо смешивать обязательства и задолженность, это разные вещи. Может быть вас сбило с толку слово "ведомость".

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

[fed]

Цитата:

Сообщение от Мартынов Дмитрий

Не надо смешивать обязательства и задолженность, это разные вещи. Может быть вас сбило с толку слово "ведомость".

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

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

Это я к тому, что независимо от степени "управленческости" учета, так сказать, следование некоторым фундаментальным принципам GAAP/IAS весьма полезно. Возможно тогда как раз удастся внедрить модуль рассчетов с поставщиками, расширяя его, а не переписывая отчетность по задолженостям с ноля...

[Мартынов Дмитрий]

Цитата:

Сообщение от fed

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

Это я к тому, что независимо от степени "управленческости" учета, так сказать, следование некоторым фундаментальным принципам GAAP/IAS весьма полезно. Возможно тогда как раз удастся внедрить модуль рассчетов с поставщиками, расширяя его, а не переписывая отчетность по задолженостям с ноля...

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

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

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