Архив форума

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

Процитировано сообщение: Климанов Александр от 03.06.2008 :: 11:33:40:

Что конкретно не нравится?

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

Здравствуйте, уважаемые.
 
Мне кажется, что предложение сергея "слегка" утопично.
Попытаюсь обосновать это:
Процитировано сообщение: Коган Сергей от 04.06.2008 :: 09:21:00:

Если устав является приложением (неотъемлемой частью) договора, то это все равно, что записать все, что вы предложили в договор.
Если устав не является частью договора, то он юридически несостоятелен. Можно написать что угодно, только от этого всегда можно отказаться.
Работа на условиях "time-material" всегда считалась выгодной для исполнителя, а не для заказчика.  
Формулировка "вознаграждение исполнителя определяется на основании ежемесячно оформляемых актов выполненных работ" - это как?
"Сколько заказчик сочтет нужным?" - так что ли?  
И какой исполнитель подпишется под таким договором?  
Тогда в процессе переговоров на первый план выходит часовая ставка специалиста. Ни разу не видел, чтобы такой вариант был дешевле, обычно на проекте с фиксированной стоимостью заказчик получает неявный бонус по ресурсам исполнителя...
 
Процитировано сообщение: Коган Сергей от 04.06.2008 :: 09:21:00:

Степень формализованности проекта слабо кореллирует с его успешностью, зато сильно - с затратами на управление проектом.  
То есть выкинуть на своего руководителя департамента 4 мес х $5000?=$20 000? не жалко? Cкажете, что он будет уделять часть времени?
В таком случае - не он управляет проектом.
 
Процитировано сообщение: Коган Сергей от 04.06.2008 :: 09:21:00:

Из области фантастики.
Оплата в конце проекта. То есть вы будете софтом пользоваться, а платить - если понравится. И кто согласится? Взломать можно все что угодно.
Софт лежит на вашем сервере 4 месяца. За это время можно его основательно крякнуть, вернуть поставщику его байты и восстановить в течение получаса, когда он скроется за горизонтом. В России живем, однако. Кроме того, имея в перспективе еще и неоплату услуг, очень заманчивая перспектива, получить издержки по персоналу плюс еще и софт подарить.
Выкуп - то же самое, только еще и попасть на НДС, налог с прибыли и в итоге - убытки, которые в нашем любимом государстве как то не вычитаются из прибыли. Почему-то...
Подарить исходники. В качестве компенсации. То есть - программа плоха, если нет исходников. А с исходниками - супер. Так и купите исходники сразу. Любой владелец кода вам с радостью их продаст. Приблизительно пол-лимона, ну кто-то лимон попросит. Хотя я бы слил и за 300. Все равно через год у нормального разработчика почти весь код поменяется, а вывести на рынок еще одну, 53-ю по счету, систему - задачка еще та...  
 
Процитировано сообщение: Коган Сергей от 04.06.2008 :: 09:21:00:

В целом, такая стратегия перекладывания всех рисков на исполнителя - нежизнеспособна. Для снижения рисков делается предпроект, то есть прорабатываются процессы до степени детализации, позволяющей оценить стоимость полной проработки и полные риски проекта.
Платить за предпроект должен Заказчик. Стоимость этого удовольствия около $20 000. В случае отрицательного результата у заказчика остается 100 листов исписанной бумаги. И все. Хотя нет, не все. Еще у него остается опыт. А цифра соизмерима с тем, что вы предлагаете заплатить своему начальнику департамента. Так что вполне реально...
 
Процитировано сообщение: Коган Сергей от 04.06.2008 :: 09:21:00:

Тайм-матириал форева. А вот софтину нахаляву - это перебор. (с)Матроскин.
 
Прошу заметить, что интересов производителей я не представляю. Просто проект - это ВЗАИМОДЕЙСТВИЕ. Позитивнее надо быть.

Отвечаю по-пунктам.
 
1. Фиксированная цена договора - это одно, а строка "бюджет проекта согласован в размере" в уставе проекта - это другое. Как правило, в уставе прописывается и процедура принятия решения о корректировке бюджета. И, как правило, она менее кровавая, чем внесение изменений в договор. То есть решение об этом согласуется на уровне рабочей группы, а дальше просто рождаются дополнительные акты выполненных работ.
 
Далее, проекты актов выполненных работ готовит не заказчик, а рабочая группа, в которую входят представители каждой стороны. Если люди настроены на работу, они обычно договариваются.
 
Все остальные рассуждения о том, на чьей стороне бонус, мне кажется, мало интересны. В крайнем случае, существуют количественные оценки сложности программного обеспечения, например FPA.
 
Более того, я вижу вполне вероятным, что гибкое внедрение займет больше времени, и будет стоить дороже, чем те же параметры фиксированного договора. Но и вероятность успешного завершения проекта соответственно, больше.
 
2. Формальные затраты на управление проектом примерно одинаковы и в том и в другом случае. Другое дело, что при гибком управлении проектом, руководитель должен реально вникать в то, что там творится, а не просто отбывать номер.
 
3. По лицензиям.
- По моим понятиям, процедура внедрения должна происходить на временных лицензиях разработчика. Потом они меняются на перманентные клиентские. Технические и правовые механизмы есть - надо их адекватно применять.
- Хакнуть у нас могут все что угодно, но надо понять разницу между "пераццким виндовсом" и WMS. Последняя, скорее всего, все равно без поддержки производителя долго не проработает. Кроме того, при подозрении на такую ситуацию можно и правоохранителей натравить - статья в УК есть, и стоимость WMS нижний предел ущерба однозначно перекроет.
- Касательно исходников - иногда поставщику приходится выбирать: либо рисковать пресс-релизом недовольного клиента о неуспешном внедрении системы, либо тихо отдать исходники, и молиться, чтобы ИТ-служба заказчика вытянула проект сама. Пять лет назад наблюдал такую ситуацию изнутри в роли ИТ-службы.
 
4. С философской точки зрения замечу, нет способа управления проектом, свободного от недостатков. Но моя практика показывает, что если стороны на самом деле точно не знают цену и требования при заключении договора - однако в договоре и приложениях прописывают их фиксированными, они напрашиваются на неприятности. В этом случае предпочтительно честно признать существующую неопределенность, и определять механизмы, которые позволят этой неопределенностью управлять.

Оговорить:
1) Оплата по этапам
2) Время реагирования на проблему
3) Ответственность исполнителя за сбои
 
 
И как сказано выше - сначала собрать побольше отзывов о внедрениях разных wms. Как от поставщика wms, так и от их клиентов.

Процитировано сообщение: Климанов Александр от 03.06.2008 :: 11:33:40:

 
Нюансов море и уверяю Вас, как представитель компании-интегратора WMS - существенного толку от бодания по договорным пунктам не особо много.  Отпишу несколько общих личных соображений на этот счет, заранее исключая рассуждения об эффективности тех или иных методик внедрения.  
 
Оценим по пятибальной шкале эффективность подходов минимизации рисков, как по дальнейшему расширению бюджета проекта в разы, так и получения совсем не того, что ожидали.  
 
Принцип выставления баллов - экспертный, т.е. навскидку, без особых обоснований.  
 
1. Поэтапная оплата, в том числе и по софту. Всегда можно определить честный и взаимовыгодный график платежей, выгодный обеим сторонам. Изучите этапность работ, если интегратор нацелен на результат он не будет активно компенсировать свои проектные риски Вашими деньгами.  
 
Эффективность: 3-4
 
2. Определите критерии приемки по каждому этапу, разработайте совместно с Заказчиком программу и методику испытаний...   Определять критерии желательно без фанатизма, т.к. это может увеличить стоимость работ, развести море бюрократии и в итоге затянуть сроки.  
 
Эффективность: 2 - 3
 
3. Наглядная и детальная демонстрация работы системы на стенде. Эффективно для оценки работы по базовой цепочке операций, без особых перегибов.  
 
Эффективность: 1 - 5 (в зависимости от сложности процессов). Хорош для малобюджетных проектов. Позволяет составить общее впечатление о системе, а в некоторых случаях и детальное в зависимости от уровня и компетентности работающего с Вами сейлза.
 
4. Предварительный инжиниринг бизнес-процессов склада - детальная пооперационная проработка технологии работы склада и определение формата интеграции с корпоративной информационной системой.  
 
Эффективность: 4 - 5. Наиболее надежный, но конечно, не идеальный.
 
Определяетесь с наиболее привлекательным для Вас поставщиком WMS и заключаете с ним договор на выполнение этих работ. Фактически - это первый этап работ по внедрению системы и примерно треть от общего объема работ, не путать с предпродажными обследованиями за 1500-3000 у.е на 3-4 листах с отражением общей ожидаемой картины на складе с WMS.
 
Безусловно, стоимость проекта при таком подходе увеличится, интегратор будет компенсировать свои риски, но достигаемые преимущества того стоят.
 
Надежность и финансовые гарантии.
Формируется рабочая группа с обеих сторон, выполняется сложная итерационная работа, результатом которой является документ с детальным описанием работы склада в контуре конкретной WMS c учетом всевозможных нюансов.  
 
Интегратор и Вы ставите подписи, т.е. утверждаете ТЗ на внедрение по которому интегратор системы ОБЯЗУЕТСЯ запустить в точности как на бумаге и этот документ прилагается к договору сразу за методикой внедрения. В договоре на оказание услуг есть соответствующие пункты, которые оговаривают ответственность сторон, т.е интегратор несет финасовую ответственность за свою работу на ясным условиях, а у Вас есть неплохой инструмент контроля. Такой подход максимально блокирует различные авантюрные заявления о всемогуществе предлагаемых решений, в итоге у Вас на руках реальная стоимость проекта и четкое понимание, что Вы получите за эти деньги.
 
Опыт и знания. Предварительная оценка готовности к подобным проектам.
В случае, если Вы не пришли к общему знаменателю по результатам выполненного инжиниринга, Вы теряете деньги (гораздо меньшие на общем фоне проектных затрат), но Ваша рабочая группа приобретает опыт и знание о настоящей технологии, отличное от пресс-релизного формата и дискуссий на общие темы по автоматизации склада. Это знание все равно понадобится при дальнейшей работе.  
 
Интегратор теряет проект. Разработанный документ передается другому интегратору и тот может точно оценить ситуацию перед формированием заявлений о стоимости проекта.

Процитировано сообщение: Еликов Антон от 28.11.2008 :: 21:02:50:

 
  безусловно подобный подход к делу практикуют все без исключения интеграторы WMS, ведь довольный заказчик - это репутация, а репутация - это один из базовых элементов данного бизнеса, а в условиях обостряющейся конкуренции может и единственный.  Даже в детально проработанном ТЗ на внедрение все не предусмотришь и на практике "шаг в влево, шаг вправо" будет выполняться.  
 
Однако договора существуют не только как элемент защиты инвестиций обеих сторон, но и внесения четкого понимания о порядке выполнения и результатах выполненных работ.  Я согласен, что проработанный договор не требуется при внедрении элементарных коробочных решений с продолжительностью работ в 3-5 дней, но если речь идет о более-менее серьезном и ответственном проекте внедрения WMS с детальным погужением в ситуацию на объекте Заказчика, то необходим и ответственный подход к договору.  
 
Именно поэтому в договорах большинства поставщиков WMS в качестве приложения присутствует методика внедрения, регламентирующая порядок работы рабочих групп со стороны Заказчика и интегратора WMS, это небходимо в первую очередь для обеспечения достижения цели клиента точно и в срок без расширения бюджета проекта.