Коллеги,
Планируем внедрение WMS.
Выбрали разработчика, но не нравится его договор.
Если кто уже внедрял на своих складах WMS, сообщите с какими нюансами можно столкнуться при внедрении, и что необходимо обязательно указывать в договоре.
Если есть возможность, вышлите шаблон договора.
:-?
Может для начала пилотный проект сделать, а там уже будет видно на что обратить внимание при составлении договора.
Это и есть пилотный проект, только получается он достаточно масштабный.
Что конкретно не нравится?
Без текста обсуждаемого договора рекомендации давать тяжело. Предполагаю, что текущую ситуацию можно описать следующим образом:
— Никто не может точно оценить перечень необходимых работ, сроки и стоимость проекта
— У заказчика нет уверенности, что он получит именно то, что хочет
— У исполнителя нет уверенности, что заказчик не захочет невозможного
— В договоре заказчику предлагается сначала купить софт, потом заплатить за доработки, а потом получить результат.
Я бы рекомендовал сделать следующее:
1. Цену в договоре не прописывать. Использовать формулировку: «вознаграждение исполнителя определяется на основании ежемесячно оформляемых актов выполненных работ». Ориентировочный бюджет проекта, сроки, и базовые требования к результатам записать в приложение к договору (в устав проекта)
2. Там же определить рабочую группу, отвечающую за ведение проекта (со стороны заказчика обязательны предметные специалисты и руководитель в ранге руководителя департамента). Обязать ее проводить рабочие совещения не реже 1 раза в две недели. Эта же группа должна готовить проекты ежемесячных актов выполненных работ.
3. Если проект предусматривает приобретение лицензий — установить следующее:
— Либо лицензии оплачиваются в конце проекта — после того как он будет признан успешным
— Либо в случае неуспеха проекта исполнитель обязуется выкупить лицензии по их первоначальной стоимости
— Либо, в случае неуспеха проекта, исполнитель передает в дополнение к лицензиям полный набор исходных текстов созданного/модифицированного программного продукта, чтобы заказчик мог самостоятельно завершить проект.
В целом, такая стратегия позволяет управлять рисками по ходу исполнения договора, постепенно уточняя и согласовывая требования сторон. С другой стороны, если выяснится, что интересы сторон не могут быть согласованы (а это выяснится в первые 1-2 месяца) — потери в денежном выражении будут не такие большие.
С другой стороны, и исполнитель не может оказаться в ситуации, когда за какую-то первоначальную сумму денег ему бесконечно предлагают доделывать и переделывать программное обеспечение не подписывая акт приемки системы. Текущие расходы на доработки будут оплачены в любом случае на основании ежемесячных актов выполненных работ. А реальную прибыль (деньги за лицензии, и т.д.) он получит только по завершении проекта.
Спасибо, за советы, очень полезная информация.
По поводу «не нравится». Ситуация в том, что перед внедрением WMS, будет проведен тендер, договор (прилагаемый к тендерной документации) должен быть общим. При анализе договоров потенциальных контрагентов стало ясно, что они стараются оградить себя от возможных рисков, а наша задача оградить себя. В связи с этим хотелось бы собрать максимальное количество информации и определить слабые места.
Вопрос, в большей степени обращен к тем, кто внедрял WMS и в процессе внедрения понял, что желательно было бы прописать те или иные моменты которые могут возникнуть на разных этапах.
можете посмотреть варианты документов гос. организаций
http://www3.pgz.economy.gov.ru/trade/view/browser/general.html?theme=10…
Здравствуйте, уважаемые.
Мне кажется, что предложение сергея «слегка» утопично.
Попытаюсь обосновать это:
Если устав является приложением (неотъемлемой частью) договора, то это все равно, что записать все, что вы предложили в договор.
Если устав не является частью договора, то он юридически несостоятелен. Можно написать что угодно, только от этого всегда можно отказаться.
Работа на условиях «time-material» всегда считалась выгодной для исполнителя, а не для заказчика.
Формулировка «вознаграждение исполнителя определяется на основании ежемесячно оформляемых актов выполненных работ» — это как?
«Сколько заказчик сочтет нужным?» — так что ли?
И какой исполнитель подпишется под таким договором?
Тогда в процессе переговоров на первый план выходит часовая ставка специалиста. Ни разу не видел, чтобы такой вариант был дешевле, обычно на проекте с фиксированной стоимостью заказчик получает неявный бонус по ресурсам исполнителя…
Степень формализованности проекта слабо кореллирует с его успешностью, зато сильно — с затратами на управление проектом.
То есть выкинуть на своего руководителя департамента 4 мес х $5000?=$20 000? не жалко? Cкажете, что он будет уделять часть времени?
В таком случае — не он управляет проектом.
Из области фантастики.
Оплата в конце проекта. То есть вы будете софтом пользоваться, а платить — если понравится. И кто согласится? Взломать можно все что угодно.
Софт лежит на вашем сервере 4 месяца. За это время можно его основательно крякнуть, вернуть поставщику его байты и восстановить в течение получаса, когда он скроется за горизонтом. В России живем, однако. Кроме того, имея в перспективе еще и неоплату услуг, очень заманчивая перспектива, получить издержки по персоналу плюс еще и софт подарить.
Выкуп — то же самое, только еще и попасть на НДС, налог с прибыли и в итоге — убытки, которые в нашем любимом государстве как то не вычитаются из прибыли. Почему-то…
Подарить исходники. В качестве компенсации. То есть — программа плоха, если нет исходников. А с исходниками — супер. Так и купите исходники сразу. Любой владелец кода вам с радостью их продаст. Приблизительно пол-лимона, ну кто-то лимон попросит. Хотя я бы слил и за 300. Все равно через год у нормального разработчика почти весь код поменяется, а вывести на рынок еще одну, 53-ю по счету, систему — задачка еще та…
В целом, такая стратегия перекладывания всех рисков на исполнителя — нежизнеспособна. Для снижения рисков делается предпроект, то есть прорабатываются процессы до степени детализации, позволяющей оценить стоимость полной проработки и полные риски проекта.
Платить за предпроект должен Заказчик. Стоимость этого удовольствия около $20 000. В случае отрицательного результата у заказчика остается 100 листов исписанной бумаги. И все. Хотя нет, не все. Еще у него остается опыт. А цифра соизмерима с тем, что вы предлагаете заплатить своему начальнику департамента. Так что вполне реально…
Тайм-матириал форева. А вот софтину нахаляву — это перебор. (с)Матроскин. :)
Прошу заметить, что интересов производителей я не представляю. Просто проект — это ВЗАИМОДЕЙСТВИЕ. Позитивнее надо быть.
Алесандр, добрый вечер.
Банки имеют очень серьезные юридические службы, которые делают очень серьезные кредитные договора.
Закон изначально на стороне интересов банков. Тем не менее их тоже кидают вполне успешно.
Это я к тому, что конечно договор важен…
Такого не бывает. По крайней мере в моей практике не было. Чтобы договор уже как условие тендера выступал. Типа публичная оферта на покупку.
Дело в том, что все программы разные. И методики внедрения у каждого поставщика свои. И степень проработки каждого этапа тоже является
отражением компетенций данного поставщика. Наличие и отсутствие конкретных этапов, разные схемы лицензирования. Я не представляю, как
всех причесать под одну гребенку. Я участвую в тендерах не первый день и даже не первый год. Причем с разных сторон. Сейчас я профессионально занимаюсь организацией тендеров по WMS для заказчиков. Я думаю, что просто невозможно сделать единый договор.
Имеете право. Главное, чтобы в манию не превратилось.:)
Все договора поставщиков, как устав внутренней службы вооруженных сил, написаны кровью. Очень интересно, по ним можно изучать, кто уже на какие грабли наступил…
Оградить от рисков нельзя. Риски можно снижать, рисками можно управлять. Риски можно перераспределить, но…
Это деструктивный путь.
Сядьте вместе с исполнителем и обсудите управление рисками. Вы поймете, что и как. То, что вам кажется слишком рискованным, конечно надо обсудить и включить в договор.
Сомнительно, что это можно сделать на форуме. Хотя это — правильный путь. Соберите информацию. У клиентов этого исполнителя она есть.
Но они вам ее вряд ли дадут. Никто не будет выносить сор из избы, это — раз. Им не с чем сравнивать, это — два.
Самый негативный сценарий:
1. Вы вибираете систему, продажники которой cамые большие Мастера Разговорного Жанра.
2. Ваши юристы бьют друг другу морды, но договариваются.
3. Ваши проджект менеджеры бьют друг другу морды и не договариваются.
Далее чередовать.
Про вопросы всякие, в том числе и проектного взаимодействия я писал, пишу и буду писать.
Почитайте «Складские технологии» и «Логистику и Управление» за прошлый и этот год.
Найдете много интересного, я Вам гарантирую.
Отвечаю по-пунктам.
1. Фиксированная цена договора — это одно, а строка «бюджет проекта согласован в размере» в уставе проекта — это другое. Как правило, в уставе прописывается и процедура принятия решения о корректировке бюджета. И, как правило, она менее кровавая, чем внесение изменений в договор. То есть решение об этом согласуется на уровне рабочей группы, а дальше просто рождаются дополнительные акты выполненных работ.
Далее, проекты актов выполненных работ готовит не заказчик, а рабочая группа, в которую входят представители каждой стороны. Если люди настроены на работу, они обычно договариваются.
Все остальные рассуждения о том, на чьей стороне бонус, мне кажется, мало интересны. В крайнем случае, существуют количественные оценки сложности программного обеспечения, например FPA.
Более того, я вижу вполне вероятным, что гибкое внедрение займет больше времени, и будет стоить дороже, чем те же параметры фиксированного договора. Но и вероятность успешного завершения проекта соответственно, больше.
2. Формальные затраты на управление проектом примерно одинаковы и в том и в другом случае. Другое дело, что при гибком управлении проектом, руководитель должен реально вникать в то, что там творится, а не просто отбывать номер.
3. По лицензиям.
— По моим понятиям, процедура внедрения должна происходить на временных лицензиях разработчика. Потом они меняются на перманентные клиентские. Технические и правовые механизмы есть — надо их адекватно применять.
— Хакнуть у нас могут все что угодно, но надо понять разницу между «пераццким виндовсом» и WMS. Последняя, скорее всего, все равно без поддержки производителя долго не проработает. Кроме того, при подозрении на такую ситуацию можно и правоохранителей натравить — статья в УК есть, и стоимость WMS нижний предел ущерба однозначно перекроет.
— Касательно исходников — иногда поставщику приходится выбирать: либо рисковать пресс-релизом недовольного клиента о неуспешном внедрении системы, либо тихо отдать исходники, и молиться, чтобы ИТ-служба заказчика вытянула проект сама. Пять лет назад наблюдал такую ситуацию изнутри в роли ИТ-службы.
4. С философской точки зрения замечу, нет способа управления проектом, свободного от недостатков. Но моя практика показывает, что если стороны на самом деле точно не знают цену и требования при заключении договора — однако в договоре и приложениях прописывают их фиксированными, они напрашиваются на неприятности. В этом случае предпочтительно честно признать существующую неопределенность, и определять механизмы, которые позволят этой неопределенностью управлять.
Добрый вечер.
Да кто же против-то? Кстати, изменения в договор — доп. соглашения подписывать не сложнее, если есть желание договариваться. Тоже ничего кровавого.
Обычно уставы, особенно хорошие уставы, возникают там, где изначальное недоверие. Соответственно с желанием договариваться имеет обратную зависимость… И успешность таких проектов — тоже.
Это жизнь.
Ну да, кого интересуют интересы противоположной стороны… Ведь если посредственно внедрим, но еще и денег не заплатим — это же успешно, не так ли? По крайней мере соотношение цена/качество будет лучше.
А вот в этом согласен. Снижение рисков надо финансировать заказчику.
Золотые слова. Если бы еще это не производило эффекта слона в посудной лавке.
С правовыми — не уверен, хотя такая деловая практика есть.
С техническими — на все воля божья, можно и вскрыть.
Я видимо уже не понимаю разницы. После работы уже с одним импортным софтом можно заставить работать что угодно, а после пары…
И я думаю, что пиратский WMS можно запустить достаточно легко.
Плохой софт, который не работает без поддержки. Дайте список, прошу на полном серьезе.
Маски шоу — фуфло. Пока до серверной доберется — все уже будет снесено. Сервак вообще можно поставить удаленно. Лучше всего в Эстонии…
Суды? C сильным не дерись, с богатым не судись (С) пословица.
Любой складской оператор раз в 100 толще любого интегратора.
О пресс-релизах и степени доверия к ним — в
Опять же — кто мешает релизнуть свой раньше и написать, что заказчик виноват.
Как средство шантажа — слАбо. Такой пресс-релиз и заказчика не красит.
Молиться чтобы кто-то другой разобрался в вашем коде и «спас» проект?
Что-то тут не чисто… Скорее всего, отдали не свои, а чужие исходники, либо партнерские,
либо ушедшего (возможно по причинам краха этого проекта) разработчика.
В любом случае — гордиться нечем. :(
Философию Вашу полностью разделяю, голосую ЗА и СТОЯ.
Оговорить:
1) Оплата по этапам
2) Время реагирования на проблему
3) Ответственность исполнителя за сбои
И как сказано выше — сначала собрать побольше отзывов о внедрениях разных wms. Как от поставщика wms, так и от их клиентов.
По моему мнению нужно обязательно требовать следующее: демонстрация системы на стенде. Т.е. Исполнитель для Заказчика после написания ТЗ создает демостенд с оборудованием и показывает как его операции будут выполняться в системе. Нужно понимать, что покупая готовую WMS систему Исполнителю не составит большого труда такое сделать. Если же Исполнитель хочет полностью перерабатывать систему под Вас, то лучше найти другую WMS систему.
Наша компания продает Кронос: WMSи такое демостенд организует Заказчику.
Нюансов море и уверяю Вас, как представитель компании-интегратора WMS — существенного толку от бодания по договорным пунктам не особо много. Отпишу несколько общих личных соображений на этот счет, заранее исключая рассуждения об эффективности тех или иных методик внедрения.
Оценим по пятибальной шкале эффективность подходов минимизации рисков, как по дальнейшему расширению бюджета проекта в разы, так и получения совсем не того, что ожидали.
Принцип выставления баллов — экспертный, т.е. навскидку, без особых обоснований. :)
1. Поэтапная оплата, в том числе и по софту. Всегда можно определить честный и взаимовыгодный график платежей, выгодный обеим сторонам. Изучите этапность работ, если интегратор нацелен на результат он не будет активно компенсировать свои проектные риски Вашими деньгами.
Эффективность: 3-4
2. Определите критерии приемки по каждому этапу, разработайте совместно с Заказчиком программу и методику испытаний… Определять критерии желательно без фанатизма, т.к. это может увеличить стоимость работ, развести море бюрократии и в итоге затянуть сроки.
Эффективность: 2 - 3
3. Наглядная и детальная демонстрация работы системы на стенде. Эффективно для оценки работы по базовой цепочке операций, без особых перегибов.
Эффективность: 1 — 5 (в зависимости от сложности процессов). Хорош для малобюджетных проектов. Позволяет составить общее впечатление о системе, а в некоторых случаях и детальное в зависимости от уровня и компетентности работающего с Вами сейлза. :)
4. Предварительный инжиниринг бизнес-процессов склада - детальная пооперационная проработка технологии работы склада и определение формата интеграции с корпоративной информационной системой.
Эффективность: 4 — 5. Наиболее надежный, но конечно, не идеальный.
Определяетесь с наиболее привлекательным для Вас поставщиком WMS и заключаете с ним договор на выполнение этих работ. Фактически — это первый этап работ по внедрению системы и примерно треть от общего объема работ, не путать с предпродажными обследованиями за 1500-3000 у.е на 3-4 листах с отражением общей ожидаемой картины на складе с WMS.
Безусловно, стоимость проекта при таком подходе увеличится, интегратор будет компенсировать свои риски, но достигаемые преимущества того стоят.
Надежность и финансовые гарантии.
Формируется рабочая группа с обеих сторон, выполняется сложная итерационная работа, результатом которой является документ с детальным описанием работы склада в контуре конкретной WMS c учетом всевозможных нюансов.
Интегратор и Вы ставите подписи, т.е. утверждаете ТЗ на внедрение по которому интегратор системы ОБЯЗУЕТСЯ запустить в точности как на бумаге и этот документ прилагается к договору сразу за методикой внедрения. В договоре на оказание услуг есть соответствующие пункты, которые оговаривают ответственность сторон, т.е интегратор несет финасовую ответственность за свою работу на ясным условиях, а у Вас есть неплохой инструмент контроля. Такой подход максимально блокирует различные авантюрные заявления о всемогуществе предлагаемых решений, в итоге у Вас на руках реальная стоимость проекта и четкое понимание, что Вы получите за эти деньги.
Опыт и знания. Предварительная оценка готовности к подобным проектам.
В случае, если Вы не пришли к общему знаменателю по результатам выполненного инжиниринга, Вы теряете деньги (гораздо меньшие на общем фоне проектных затрат), но Ваша рабочая группа приобретает опыт и знание о настоящей технологии, отличное от пресс-релизного формата и дискуссий на общие темы по автоматизации склада. Это знание все равно понадобится при дальнейшей работе.
Интегратор теряет проект. Разработанный документ передается другому интегратору и тот может точно оценить ситуацию перед формированием заявлений о стоимости проекта.
может быть утопичная мысль, но все же озвучу.
А может быть стоит учитывать эфимерный фактор доверия?
В моей практике очень часто интегратор идет на то, что закрывает глаза на какие-то положения уже подписанного договора с достаточно меркантильной целью — получить преференции от заказчика. довольный заказчик — это тысячи возможностей. недовольный заказчик — миллионы потерь.
:) безусловно подобный подход к делу практикуют все без исключения интеграторы WMS, ведь довольный заказчик — это репутация, а репутация — это один из базовых элементов данного бизнеса, а в условиях обостряющейся конкуренции может и единственный. Даже в детально проработанном ТЗ на внедрение все не предусмотришь и на практике «шаг в влево, шаг вправо» будет выполняться.
Однако договора существуют не только как элемент защиты инвестиций обеих сторон, но и внесения четкого понимания о порядке выполнения и результатах выполненных работ. Я согласен, что проработанный договор не требуется при внедрении элементарных коробочных решений с продолжительностью работ в 3-5 дней, но если речь идет о более-менее серьезном и ответственном проекте внедрения WMS с детальным погужением в ситуацию на объекте Заказчика, то необходим и ответственный подход к договору.
Именно поэтому в договорах большинства поставщиков WMS в качестве приложения присутствует методика внедрения, регламентирующая порядок работы рабочих групп со стороны Заказчика и интегратора WMS, это небходимо в первую очередь для обеспечения достижения цели клиента точно и в срок без расширения бюджета проекта.
Пожалуйста, войдите или зарегистрируйтесь, чтобы комментировать.