Начинаем работу по проекту перевода отдела логистики (от адресного хранения, до EDI) на 1С. Нахожусь со стороны Заказчика. Определен оптимальный подрядчик и с ним ведется предварительная проработка. Далее участие будет предложено еще нескольким подрядчикам.
Специфика проекта:
1. Невозможность разбить проект на блоки.
2. Крайне высокий уровень кастомизации.
3. Отсутствие штатных специалистов 1С и невозможность привлечь их в небольшой город за вменяемые деньги.
4. Работа в режиме 24/7.
5. Значительная сумма затрат по проекту.
6. Наличие самых разнообразных штрафных санций от сетей в случае несвоевременной поставки товара.
7. Простой дня складского терминала оценивается среднепотолочно более 20 млн рублей.
Вангую. Заключаем договор с интегратором. Год продуктивно работаем, тестируем, работаем, тестируем, обучаем, подписываем промежуточные акты, платим деньги, работаем, подписываем, платим, работаем, подписываем, платим, и т.д.
К запуску более 50%, а я так подозреваю все 70% будут уже интегратору оплачены.
Далее "завтра мы работаем в новой системе". Запускаем по сценарию. И тут система оттестированная перетестированная начинает выдавать кренделечки крендельки. Эти "хлебуболочные изделия" могут привести к потерям и штрафам, которые будут превышать впринципе всю стоимость договора с интегратором.
Тут возникает дилема.
1. Если мы предъявим это интегратору он в лучшем случае просто свалит недополучив свои 30% по проекту. Мы у разбитого корыта.
2. Если мы попытаемся заложить риски в договор в виде "интегратор несет ответственность за все реальные убытки" - такой договор никто не подпишет.
3. Если мы попытаемся указать в договоре, что 50% суммы интегратор получает после успешного запуска, то стоимость договора автоматически сильно увеличивается, т.к. интегратор захочет нивелировать свои риски.
4. Выстраивать доверительные отношения с интегратором - согласен, но не на много миллионных проектах.
Есть ли впринципе какая-то панацея в нашем случае, которая бы позволила и интегратору и Заказчику понимать, что если будут проблемы на запуске, то это все предусмотрено так-то и так и не надо бегать с выпученными глазами тыкая друг в друга пальцами.
Специфика проекта:
1. Невозможность разбить проект на блоки.
2. Крайне высокий уровень кастомизации.
3. Отсутствие штатных специалистов 1С и невозможность привлечь их в небольшой город за вменяемые деньги.
4. Работа в режиме 24/7.
5. Значительная сумма затрат по проекту.
6. Наличие самых разнообразных штрафных санций от сетей в случае несвоевременной поставки товара.
7. Простой дня складского терминала оценивается среднепотолочно более 20 млн рублей.
Вангую. Заключаем договор с интегратором. Год продуктивно работаем, тестируем, работаем, тестируем, обучаем, подписываем промежуточные акты, платим деньги, работаем, подписываем, платим, работаем, подписываем, платим, и т.д.
К запуску более 50%, а я так подозреваю все 70% будут уже интегратору оплачены.
Далее "завтра мы работаем в новой системе". Запускаем по сценарию. И тут система оттестированная перетестированная начинает выдавать кренделечки крендельки. Эти "хлебуболочные изделия" могут привести к потерям и штрафам, которые будут превышать впринципе всю стоимость договора с интегратором.
Тут возникает дилема.
1. Если мы предъявим это интегратору он в лучшем случае просто свалит недополучив свои 30% по проекту. Мы у разбитого корыта.
2. Если мы попытаемся заложить риски в договор в виде "интегратор несет ответственность за все реальные убытки" - такой договор никто не подпишет.
3. Если мы попытаемся указать в договоре, что 50% суммы интегратор получает после успешного запуска, то стоимость договора автоматически сильно увеличивается, т.к. интегратор захочет нивелировать свои риски.
4. Выстраивать доверительные отношения с интегратором - согласен, но не на много миллионных проектах.
Есть ли впринципе какая-то панацея в нашем случае, которая бы позволила и интегратору и Заказчику понимать, что если будут проблемы на запуске, то это все предусмотрено так-то и так и не надо бегать с выпученными глазами тыкая друг в друга пальцами.
Найденные решения
(26) Вы забываете, что успешное внедрение - результат СОВМЕСТНОГО труда заказчика и исполнителя. Невозможно тупо баблом обеспечить успешное внедрение. Бабло - условие необходимое, но не достаточное. Требуются значительные системные усилия со стороны заказчика. Даже лучшая на рынке внедренческая команда не может вам гарантировать успешное внедрение. Они не могут контролировать все риски. И соответственно не возьмут на себя полную юридическую ответственность за возможный провал. И чем выше вы будете требовать уровень юридической ответственности (относительно стандартного по больнице, т.е. - почти никакой), тем просто будете повышать стоимость проекта. А начиная с неконтролируемого уровня рисков с вами просто откажутся иметь дело.
Заваливать проект - не в интересах нормального внедренца. Ему интересно продавать свои услуги за адекватную стоимость и пополнять свое портфолио успешных проектов. Но при этом не надо забывать, что вы обычный клиент. И на вас свет клином не сошелся. Шантажировать условиями договора, заставляя исполнителя расплачиваться за бестолковость заказчика - не получится.
Нужно просто тщательно выбрать исполнителя, тщательно спланировать вместе с ним все работы и обязательно разбить на возможно большее число этапов, плотно контролировать каждый этап и оплачивать все этапы отдельно. Со своей стороны - заручиться карт-бланшем от топ-менеджмента, составить внедренческую команду специалистов заказчика. Продумать графики и ход совещаний, как своих, так и совместных и согласовать их. Обеспечить доступность специалистов заказчика и максимально их разгрузить на время работы в проекте, при этом желательно дополнительно простимулировать материально.
ЗЫ. Я бы даже высказал такую крамольную мысль, что успех или неуспех проекта в гораздо большей степени зависит от заказчика, а не от исполнителя. А если вы собрались просто попытаться застраховаться с юридической стороны, заплатить денег и ждать отчета о успешном внедрении, будьте уверены - юристы вам понадобятся.
Заваливать проект - не в интересах нормального внедренца. Ему интересно продавать свои услуги за адекватную стоимость и пополнять свое портфолио успешных проектов. Но при этом не надо забывать, что вы обычный клиент. И на вас свет клином не сошелся. Шантажировать условиями договора, заставляя исполнителя расплачиваться за бестолковость заказчика - не получится.
Нужно просто тщательно выбрать исполнителя, тщательно спланировать вместе с ним все работы и обязательно разбить на возможно большее число этапов, плотно контролировать каждый этап и оплачивать все этапы отдельно. Со своей стороны - заручиться карт-бланшем от топ-менеджмента, составить внедренческую команду специалистов заказчика. Продумать графики и ход совещаний, как своих, так и совместных и согласовать их. Обеспечить доступность специалистов заказчика и максимально их разгрузить на время работы в проекте, при этом желательно дополнительно простимулировать материально.
ЗЫ. Я бы даже высказал такую крамольную мысль, что успех или неуспех проекта в гораздо большей степени зависит от заказчика, а не от исполнителя. А если вы собрались просто попытаться застраховаться с юридической стороны, заплатить денег и ждать отчета о успешном внедрении, будьте уверены - юристы вам понадобятся.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
1. Надо, будет дороже в сумме контрактов, но дешевле с учетом простоев, убытков и т.п.
2. По отношению к чему крайне высокий уровень кастомизации? Может базовая конфигурация неправильно выбрана? Или хочется все затолкать в одно место? Вы не уникальны (простите), смотрите как и что автоматизировано у конкурентов или компаний со схожими процессами.
3. Зачем тогда автоматизация на 1С, если ее поддерживать элементарно некому?
4. Тем более с учетом 3 :)
5. Значительная для кого? :)
6. Именно поэтому бить на блоки, интегрировать с существующими на время совместного функционирования, внедряться небольшими участками
1. Надо, будет дороже в сумме контрактов, но дешевле с учетом простоев, убытков и т.п.
2. По отношению к чему крайне высокий уровень кастомизации? Может базовая конфигурация неправильно выбрана? Или хочется все затолкать в одно место? Вы не уникальны (простите), смотрите как и что автоматизировано у конкурентов или компаний со схожими процессами.
3. Зачем тогда автоматизация на 1С, если ее поддерживать элементарно некому?
4. Тем более с учетом 3 :)
5. Значительная для кого? :)
6. Именно поэтому бить на блоки, интегрировать с существующими на время совместного функционирования, внедряться небольшими участками
"Невозможность разбить проект на блоки" - а придется. Да, скорее всего - за счет увеличения стоимости проекта.
В противном случае, если проект в самом деле объемный - никакого перехода "по рубильнику" при работе 24/7 у вас не получится.
Отсутствие хотя бы одного штатного специалиста 1С тоже слабо вяжется с рисками многомиллионных убытков.
"Фигня какая-то" (с)
В противном случае, если проект в самом деле объемный - никакого перехода "по рубильнику" при работе 24/7 у вас не получится.
Отсутствие хотя бы одного штатного специалиста 1С тоже слабо вяжется с рисками многомиллионных убытков.
"Фигня какая-то" (с)
У меня одного вызывает когнитивный диссонанс следующее: "простой одного дня стоит 20 млн" и "невозможность привлечь за вменяемые деньги"? Стоимость пары нормальных программистов будет 2-3 млн в год!
Теперь по тексту:
1. Разбить на блоки всегда можно, в том числе и с "костылями" которые предлагались.
2. Высокая кастомизация - как раз причина п.1.
3. Если не можете пригласить "вживую", пробуйте постоянку на удаленке.
4. Тем более надо пару прогеров минимум :)
5. 6. 7. а кто сказал, что "попали в сказку"? ;)
Панацеи нет, при выборе интегратора выбирайте того, кто уже делал подобную вещь. И обязательно пообщайтесь с теми у кого внедрялось. Какие результаты, какие были проблемы. Риски про реальные убытки - занести не сможете, под такое никто не подпишется :) Очень вдумчиво и по максимальной программе проводите опытную эксплуатацию. Если не сможете обеспечить разбитие на блоки - тестируйте все равно по частям, но с обязательным прогоном по всему готовому функционалу, т.к. могли сломать то, что работало пока писали новое. У вас "высокий уровень кастомизации" - то соответственно ошибки - будут. Требуйте гарантийного обслуживания разработанной системы.
Теперь по тексту:
1. Разбить на блоки всегда можно, в том числе и с "костылями" которые предлагались.
2. Высокая кастомизация - как раз причина п.1.
3. Если не можете пригласить "вживую", пробуйте постоянку на удаленке.
4. Тем более надо пару прогеров минимум :)
5. 6. 7. а кто сказал, что "попали в сказку"? ;)
Панацеи нет, при выборе интегратора выбирайте того, кто уже делал подобную вещь. И обязательно пообщайтесь с теми у кого внедрялось. Какие результаты, какие были проблемы. Риски про реальные убытки - занести не сможете, под такое никто не подпишется :) Очень вдумчиво и по максимальной программе проводите опытную эксплуатацию. Если не сможете обеспечить разбитие на блоки - тестируйте все равно по частям, но с обязательным прогоном по всему готовому функционалу, т.к. могли сломать то, что работало пока писали новое. У вас "высокий уровень кастомизации" - то соответственно ошибки - будут. Требуйте гарантийного обслуживания разработанной системы.
Нужны штатные программисты, 2 хотя бы. Наличие своих программистов может нивелировать ряд проблем, а так как бизнес кастомизирован под каждого клиента то надо будет вносить изменения в проект, для новых клиентов. А вообще в логистике события развиваются очень быстро, этот факт требует от ИС компании гибкости. А значит высокой скорости внесения изменений в ИС.
Спасибо за отклики. А если подойти к вопросу с точки зрения юриста.
1. Есть договор на внедрение на базе составленного ТЗ.
ТЗ это не проект на строительство моста. Тут не расписано все вплоть до болтика иначе это было бы не ТЗ, а программный код. Это ключевой нюанс. Я думаю все понимают, что в этом случае интегратор может впаривать в арбитраже любую нерабочую хрень как идеально работающую. Судьи не АйТишники. И если кто-то думает, что ходатайство о привлечении независимого эксперта для решения спора всегда удовлетворяется - разочарую.
Продолжает забивать гвозди.
2. Договор на 10 млн (предположим).
Без предоплаты в 40% врядли интегратор возьмется выполнять работы по проекту с такими рисками.
Таким образом уже почти половину по каждому из этапов, которые даже еще не выполнялись, интегратор заработал. Попробуй у него потом отжать это в арбитраже. Даже если к этапу N на 1 млн рублей проект еще не подошел интегратор предъявив некие наработки и листы учета рабочего времени может отжать с Заказчика деньги (как минимум не возвращать авансовую часть по этому этапу).
3. Как не возьмутся без 40% аванса, так и не возьмутся без 20%-го последнего платежа. Другими словами на момент запуска системы будет оплачено 80%. Впринципе все думаю понимают, что если система не взлетит или будет слишком много крика, то интегратор пожертвует этими 20%ми и ничего Заказчик ему не сделает.
Безрадостная картина для Заказчика. :) По Грибоедову.
1. Есть договор на внедрение на базе составленного ТЗ.
ТЗ это не проект на строительство моста. Тут не расписано все вплоть до болтика иначе это было бы не ТЗ, а программный код. Это ключевой нюанс. Я думаю все понимают, что в этом случае интегратор может впаривать в арбитраже любую нерабочую хрень как идеально работающую. Судьи не АйТишники. И если кто-то думает, что ходатайство о привлечении независимого эксперта для решения спора всегда удовлетворяется - разочарую.
Продолжает забивать гвозди.
2. Договор на 10 млн (предположим).
Без предоплаты в 40% врядли интегратор возьмется выполнять работы по проекту с такими рисками.
Таким образом уже почти половину по каждому из этапов, которые даже еще не выполнялись, интегратор заработал. Попробуй у него потом отжать это в арбитраже. Даже если к этапу N на 1 млн рублей проект еще не подошел интегратор предъявив некие наработки и листы учета рабочего времени может отжать с Заказчика деньги (как минимум не возвращать авансовую часть по этому этапу).
3. Как не возьмутся без 40% аванса, так и не возьмутся без 20%-го последнего платежа. Другими словами на момент запуска системы будет оплачено 80%. Впринципе все думаю понимают, что если система не взлетит или будет слишком много крика, то интегратор пожертвует этими 20%ми и ничего Заказчик ему не сделает.
Безрадостная картина для Заказчика. :) По Грибоедову.
(13)
(13)
интегратор может впаривать в арбитраже любую нерабочую хрень как идеально работающую
- это очень спорный вопрос. Думаю можно доказать...
(13)
Попробуй у него потом отжать это в арбитраже
- то есть заранее планируете "отжимать"... Оплачивайте и принимайте каждый этап отдельно. Если возникли проблемы на первом этапе, то не поздно расторгнуть договор. Рискуете только предоплатой по первому этапу...
(13)
Фигня, ТЗ и Техпроект можно составить очень подробно. Форму - за формой, вплоть до реквизитов и алгоритмов расчета. Вот только стоимость и сроки разработки такого результата будут высокими. Готовы платить - делайте.
Допустим :)
В договоре, по пункту принятия работ, как правило стоит что-то типа: в течении NN с момента предоставления акта выполненных работ, предоставить мотивированный отказ или работы считаются принятыми.
Так вот, если ТЗ составлено шаляй-валяй, то это интегратор фактически будет вам доказывать, что он правильно сделал работу. Если вы не будете тормозить, а предоставлять ему списки замечаний - будет пахать и доводить "до ума".
ТЗ это не проект на строительство моста. Тут не расписано все вплоть до болтика иначе это было бы не ТЗ, а программный код. Это ключевой нюанс.
Фигня, ТЗ и Техпроект можно составить очень подробно. Форму - за формой, вплоть до реквизитов и алгоритмов расчета. Вот только стоимость и сроки разработки такого результата будут высокими. Готовы платить - делайте.
2. Договор на 10 млн (предположим)
Допустим :)
Попробуй у него потом отжать это в арбитраже.
В договоре, по пункту принятия работ, как правило стоит что-то типа: в течении NN с момента предоставления акта выполненных работ, предоставить мотивированный отказ или работы считаются принятыми.
Так вот, если ТЗ составлено шаляй-валяй, то это интегратор фактически будет вам доказывать, что он правильно сделал работу. Если вы не будете тормозить, а предоставлять ему списки замечаний - будет пахать и доводить "до ума".
(17)
В итоге это интегратору надоест. И он бросит проект. Вы останетесь с нерабочей системой.
Вопрос нужно ставить правильно. Мы хотим получить работающую систему или пытаться отжимать интегратора пока он не бросит работу?
Так вот, если ТЗ составлено шаляй-валяй, то это интегратор фактически будет вам доказывать, что он правильно сделал работу. Если вы не будете тормозить, а предоставлять ему списки замечаний - будет пахать и доводить "до ума".
В итоге это интегратору надоест. И он бросит проект. Вы останетесь с нерабочей системой.
Вопрос нужно ставить правильно. Мы хотим получить работающую систему или пытаться отжимать интегратора пока он не бросит работу?
(17) Да, действительно пункт о мотивированных отказах есть. И срок я по этому пункту даже немного увеличил. На практике ни разу не использовал, т.к. мотивированно мотивировал подрядчика на исправления еще до передачи акта. А с юридической точки зрения - да, согласен, это реальный рычаг. Главное, чтобы это не было многоитерационной последовательностью. Надо по максимуму за отведенные дни выдать подрядчику свои мотивации. Если подрядчик не заведомо балбес, то он все исправит. А если будет написано "че за хрень Вы мне тут сделали я не согласен", тогда подрядчик ничего не сможет и главное не захочет сделать.
(20) Подрядчик это предприниматель. Основная цель предпринимательства - зарабатывание денег. Что и делают все подрядчики. Когда заходит речь о плохих Заказчиках - я хочу сказать одно - под дулом пистолета Подрядчика никто не тянет на проект. Он сам идет. И удивляться потом, что Заказчик был шелковый и пушистый, а потом оказался жутким неадекватом не надо. Если есть такое удивление - расслабляемся и читаем договор. Если подрядчик решил довериться Заказчику и начал работать по добренькому договору, то извините - это Бизнес.
А вот Саша Лебедев данным постом как раз и пытается понять как составить правильный договор, чтобы не ругаться на возможного неадекватного подрядчика, а расслабиться и читать договор. :)
(20) Подрядчик это предприниматель. Основная цель предпринимательства - зарабатывание денег. Что и делают все подрядчики. Когда заходит речь о плохих Заказчиках - я хочу сказать одно - под дулом пистолета Подрядчика никто не тянет на проект. Он сам идет. И удивляться потом, что Заказчик был шелковый и пушистый, а потом оказался жутким неадекватом не надо. Если есть такое удивление - расслабляемся и читаем договор. Если подрядчик решил довериться Заказчику и начал работать по добренькому договору, то извините - это Бизнес.
А вот Саша Лебедев данным постом как раз и пытается понять как составить правильный договор, чтобы не ругаться на возможного неадекватного подрядчика, а расслабиться и читать договор. :)
(21)Саша Лебедев настроился не на работу по запуску информационной системы предприятия а на провал проекта с последующими отжиманием подрядчика.
Вы можете потом в расслабленном состоянии читать договор хоть до дыр. Договор это далеко не работающая система. Ваша цель это работающая система, а не договор?
Саботажников со стороны заказчиков мы то же видели это то же отдельная история. Улыбаются заказчик и исполнитель на проекте ровно до того момента как надо сдавать работы и получать деньги... И вот тут то оказывается что заказчик имел ввиду не то, а исполнитель делал всё не так. Но формально по договору и ТЗ вроде как все делали всё правильно.
Когда заходит речь о плохих Заказчиках - я хочу сказать одно - под дулом пистолета Подрядчика никто не тянет на проект. Он сам идет. И удивляться потом, что Заказчик был шелковый и пушистый, а потом оказался жутким неадекватом не надо. Если есть такое удивление - расслабляемся и читаем договор.
Вы можете потом в расслабленном состоянии читать договор хоть до дыр. Договор это далеко не работающая система. Ваша цель это работающая система, а не договор?
Саботажников со стороны заказчиков мы то же видели это то же отдельная история. Улыбаются заказчик и исполнитель на проекте ровно до того момента как надо сдавать работы и получать деньги... И вот тут то оказывается что заказчик имел ввиду не то, а исполнитель делал всё не так. Но формально по договору и ТЗ вроде как все делали всё правильно.
(22) Согласен, результатом должна быть работающая система. К ней и идем. Ну и дуем на воду обжегшися на молоке. :)
С самого начала (т.е. с договора) хочу, чтобы подрядчик понял, что улыбок не будет.
Изучив различные источники безумных пространств интернетов я четко уяснил, что каждое второе внедрение WMS провально. А достаточно часто и повторное внедрение также провально.
Чем мы хуже? :)
С самого начала (т.е. с договора) хочу, чтобы подрядчик понял, что улыбок не будет.
Изучив различные источники безумных пространств интернетов я четко уяснил, что каждое второе внедрение WMS провально. А достаточно часто и повторное внедрение также провально.
Чем мы хуже? :)
(23)
А причины провалов известны? И критерии, по которым считаем, что проект "провалился" (ну чтобы было однозначное понимание у нас термина "провал")
Изучив различные источники безумных пространств интернетов я четко уяснил, что каждое второе внедрение WMS провально. А достаточно часто и повторное внедрение также провально.
А причины провалов известны? И критерии, по которым считаем, что проект "провалился" (ну чтобы было однозначное понимание у нас термина "провал")
(25) Скажу честно. Основными источниками, по информации из которых я составил мнение о провальных проектах это инфостарт и миста.
Причины. А вот тут засада. Подавляющее большинство - обхекавшиеся (возможно и по объективным и по независящим от них причинам) молчуны. А меньшинство - это неудовлетворение ожидания Заказчика по деньгам или по работе системы в боевом режиме. Разочарование возникает либо на начальном этапе, когда вываливают ценник, либо на последнем этапе, когда система запущена.
Все это естественно крайне субъективно.
Причины. А вот тут засада. Подавляющее большинство - обхекавшиеся (возможно и по объективным и по независящим от них причинам) молчуны. А меньшинство - это неудовлетворение ожидания Заказчика по деньгам или по работе системы в боевом режиме. Разочарование возникает либо на начальном этапе, когда вываливают ценник, либо на последнем этапе, когда система запущена.
Все это естественно крайне субъективно.
(26) Вы забываете, что успешное внедрение - результат СОВМЕСТНОГО труда заказчика и исполнителя. Невозможно тупо баблом обеспечить успешное внедрение. Бабло - условие необходимое, но не достаточное. Требуются значительные системные усилия со стороны заказчика. Даже лучшая на рынке внедренческая команда не может вам гарантировать успешное внедрение. Они не могут контролировать все риски. И соответственно не возьмут на себя полную юридическую ответственность за возможный провал. И чем выше вы будете требовать уровень юридической ответственности (относительно стандартного по больнице, т.е. - почти никакой), тем просто будете повышать стоимость проекта. А начиная с неконтролируемого уровня рисков с вами просто откажутся иметь дело.
Заваливать проект - не в интересах нормального внедренца. Ему интересно продавать свои услуги за адекватную стоимость и пополнять свое портфолио успешных проектов. Но при этом не надо забывать, что вы обычный клиент. И на вас свет клином не сошелся. Шантажировать условиями договора, заставляя исполнителя расплачиваться за бестолковость заказчика - не получится.
Нужно просто тщательно выбрать исполнителя, тщательно спланировать вместе с ним все работы и обязательно разбить на возможно большее число этапов, плотно контролировать каждый этап и оплачивать все этапы отдельно. Со своей стороны - заручиться карт-бланшем от топ-менеджмента, составить внедренческую команду специалистов заказчика. Продумать графики и ход совещаний, как своих, так и совместных и согласовать их. Обеспечить доступность специалистов заказчика и максимально их разгрузить на время работы в проекте, при этом желательно дополнительно простимулировать материально.
ЗЫ. Я бы даже высказал такую крамольную мысль, что успех или неуспех проекта в гораздо большей степени зависит от заказчика, а не от исполнителя. А если вы собрались просто попытаться застраховаться с юридической стороны, заплатить денег и ждать отчета о успешном внедрении, будьте уверены - юристы вам понадобятся.
Заваливать проект - не в интересах нормального внедренца. Ему интересно продавать свои услуги за адекватную стоимость и пополнять свое портфолио успешных проектов. Но при этом не надо забывать, что вы обычный клиент. И на вас свет клином не сошелся. Шантажировать условиями договора, заставляя исполнителя расплачиваться за бестолковость заказчика - не получится.
Нужно просто тщательно выбрать исполнителя, тщательно спланировать вместе с ним все работы и обязательно разбить на возможно большее число этапов, плотно контролировать каждый этап и оплачивать все этапы отдельно. Со своей стороны - заручиться карт-бланшем от топ-менеджмента, составить внедренческую команду специалистов заказчика. Продумать графики и ход совещаний, как своих, так и совместных и согласовать их. Обеспечить доступность специалистов заказчика и максимально их разгрузить на время работы в проекте, при этом желательно дополнительно простимулировать материально.
ЗЫ. Я бы даже высказал такую крамольную мысль, что успех или неуспех проекта в гораздо большей степени зависит от заказчика, а не от исполнителя. А если вы собрались просто попытаться застраховаться с юридической стороны, заплатить денег и ждать отчета о успешном внедрении, будьте уверены - юристы вам понадобятся.
У меня есть неприятный опыт работы с подрядчиком по крупному проекту и наевшись вводя туда названия интеграторов и изучая решения судов теперь стал параноиком.
Очень интересное предложение по авансу. Об этом кстати не подумал. А то всегда работали по схеме, что предоплата платится от суммы всего договора и состоит из "подавансов" по каждому из этапов.
Не факт, что по такой схеме со мной захотят работать, но очень интересно.
Очень интересное предложение по авансу. Об этом кстати не подумал. А то всегда работали по схеме, что предоплата платится от суммы всего договора и состоит из "подавансов" по каждому из этапов.
Не факт, что по такой схеме со мной захотят работать, но очень интересно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот