V.Sopkin
1. Поэтому отсутствие информации об удачных внедрениях можно объяснить либо действительно их малым количеством, либо отсутствием "удачных" внедренцев на данном форуме , либо нежеланием делиться своим положительным опытом, либо отсутствием свободного времени для общения у "удачных" внедренцев. Хотя форумы и создаются с целью обмена опытом..).

1) Очень сложно судить об удачности внедрения. Ошибки и просчеты внедренцев в основном всплывают уже после их ухода. Т.Е. Внедренци часто не видят результаты своей работы и могут говорить не об удачности внедреня, а лишь о результативности запуска.
2) Удачные решения просты и очевидны, по этому для людей которые их внедрили это просто текучка, о которой даже не стоит упоминать. А в случае просчета есть над чем подумать и что обсудить.
3) Удачные внедренцы себя редко такими считают. Про себя скорее скажет "Сильный внедренец".
4) Времени не хватает только плохим внедренцам, а хорошим на форуме становится быстро скучно. Одни и теже проблемы и вопросы, хотя не исключаю вариант что некотрые сидят в форумах чтобы пиариться.


V.Sopkin
2. Крупные проекты - это наверное громко связано. Я бы поправился - сложные проекты. А это может быть проект ERP или просто набор взаимосвязанных подсистем (недотягивающих до ERP), или реализация интеграции систем разных производителей, или систем разных типов (АСУП, АСУ ТП, САПР и т.д.).

Крупные и мелкие проекты не очень сильно отличаются. Задачи решаются примерно одни и теже, разница только в количествах нулей. Мелкие наверно даже сложнее.

andbary Флеймер
1) Очень сложно судить об удачности внедрения.
2) Удачные решения просты и очевидны
1. Не понимаю! Или внедрили или нет... Если система не внедрена, то как она может быть удачной?
Естественно есть тестовая эксплуатация... и если система не сможет проработать хотя бы год, то как она может быть внедрена. Если клиент увидит просчеты, то он напомнит о них очень быстро.
2. Что бы сделать решение простым и очевидным необходимо затратить очень много сил...

Меня очень интересуют различные решения по бизнес операциям. Схемы и описания... Готов поделиться своими в каком угодно виде (хошь презентации в РР).

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

1.2 Не факт что напомнят. Проектные решения тестируются и подписываются заказчиком, и если это не очевидная ошибка в разработке, то претензию предъявить очень сложно. Решить самим бывает проще и дешевле особенно если консультанты оставили после себя хорошу обученную команду из сотрудников заказчика.

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

andbary
Меня очень интересуют различные решения по бизнес операциям. Схемы и описания... Готов поделиться своими в каком угодно виде (хошь презентации в РР).

По мойму, подобные решения очень сильно зависят от внедряемой системы. То что одна система подерживат просто и естествено в другой может оказаться достаточно сложным решением и даже усложнть работу пользователя.
Например, в ОА возвраты денег клиенту. Или оформление возврата предоплаты от поставщика достаточно громоздкий процесс. В то время, как в Аксапте это одна простая и естественная операция.

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

Calm авторКрупные и мелкие проекты не очень сильно отличаются. Задачи решаются примерно одни и теже, разница только в количествах нулей. Мелкие наверно даже сложнее.

Какое-то странное утверждение. Особенно в его последней части.

Если чесно, то когда я писал, то перепутал понятия: "Проект в крупной компании" и "Крупный проект".

Но когда перечитал, то понял, что все равно утверждение верно, особенно для последней части.

У мелких проектов гораздо выше динамика. Иногда задачи на которые консультант по ОEBS тратит недели, специалист по 1С решает за часы.

Крупные проекты проектируются и ведутся по какой нибудь методолгии. Например AIM или MBS проект как бы ставится на конвейер. В то время как в малых проектах больше приходится ипровизировать.

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

andbary Флеймер- Да. Но хрено-о-ово. Исходя из большого опыта, могу сказать что "хреново" хватает на 1 (один) год... а дальше или контора исчезнет или решение...

Если остается обученная команда способная справиться с задачами, то это очень удачно.

За любым действием стоят схемы операций, иногда на казалось бы простой операции (нажатие кнопочки) стоит очень серьезный алгоритм.


И... ?

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

andbary
Если остается обученная команда способная справиться с задачами, то это очень удачно.

Иногда остаются внедренцы.

andbary
За любым действием стоят схемы операций, иногда на казалось бы простой операции (нажатие кнопочки) стоит очень серьезный алгоритм.

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