Добрый день, прошу совета форумчан.
Стоим на стадии заключения достаточно рискового договора на разработку и внедрение достаточно серьезной и сильно кастомизированной логистической системы. Имеется старая система, которую предполагается перевести на 1С, но не создание клона, а полностью изменить архитектуру и методику работы. Старая система далеко не идеал.
Исходя из своего предыдущего опыта и тех граблей, на которые уже наступали при первичных попытках реализации этого проекта тезисно:
1. Тендер и конкурсы исключаю сразу. Трудозатратно, а плюсов мало. Предварительные проработки со всеми крупными интеграторами уже проведены. Определены два, на которых будем ориентироваться.
2. Составляем договор и делим его на два блока - составление ТЗ и разработка и внедрение решение по этому ТЗ. В договоре прописан каждый чих, т.к. впринципе интеграторы 1С не дорожат своей репутацией и 1С на это никак не влияет, следовательно легко окажемся в арбитраже. И тут должно быть все железобетонно. Я очень добрый человек, но часто наступал на грабли, поэтому доверяю только бумагам с подписями и печатями.
3. Интегратор пишет ТЗ.
4. Интегратор оценивает разработку и внедрение согласно ТЗ.
5. Если мы сошлись в цене, то начинает работы по ТЗ. Если не сошлись - работы по ТЗ начинает другой интегратор.
Встает вопрос о том, как сделать ТЗ (имею ввиду и ТЗ и техпроект).
а) оформление по ГОСТам это только оформление. Требования к содержанию совершенно поверхностные. Я могу написать ТЗ по ГОСТу, но в арбитраже Заказчик пролетит с ним как фанера над Парижем и заплатит интегратору по полной.
б) так что речь сейчас не о правилах оформления. Речь о том, как сделать ТЗ реально тем документом на основании которого внедрение может проводиться не только тем интегратором, который его разрабатывал, но также сделать его юридически полноценным.
в) N лет назад я считал, что фраза в договоре "...должно быть исчерпывающим." вполне достаточна.
г) да, мантра бОльшего числа статей этого форума заключается в том, чтобы потратить время на выстраивание доверительных отношений с подрядчиком. Ну ну. В арбитраже Вы как окажетесь - увидите как спалились все Ваши так долго выстраиваемые доверительные отношения в одну секунду всего из-за каких-то там 500 тысяч, по которым почему-то не удалось договориться.
д) как юридически грамотно оформить договор и ТЗ я знаю.
Это все была прелюдия. Теперь собственно вопрос. Он звучит просто.
"Как в договоре обозначить (сформулировать) необходимый уровень детализации технического задания?"
Приведу пример (очень условно).
1. Первый уровень.
"ТЗ должно быть исчерпывающим."
2. Второй уровень.
"...все процессы должны быть описаны четко, лаконично, с блок-схемами, и отражать реальную специфику..."
3. Третий уровень.
"...вот тут что-то должно быть написано..."
4. Четвертый уровень.
Собственно это самый низки уровень. Самый лучший уровень. Программный код. :-)
Так вот. Как сформулировать третий уровень так, чтобы четко дать интегратору понять, что я хочу реально детального описания. А самое главное - это должна быть очень простая формулировка, которая, в случае испортившихся отношений и попыткой интегратора подсунуть фуфло со словами "Это ТЗ. Видите тут в заголовке написано ТЗ, значит это ТЗ. Подписывайте акт." однозначно трактовалось в арбитраже как фуфло.
Субъективно - такую формулировку найти невозможно, но надежда конечно есть. :)
Если не получится - составление ТЗ придется дробить на мелки блоки и интегратор будет их выполнять по очереди. Уровень детализации устраивает - подписываем акт и переходим к описанию следующего блока. Не устраивает - не подписываем акт и останавливаем работы по договору. Ищем другого интегратора. Текущий же интегратор идет в суд и получает деньги за неподписанный этап. Заказчик потерял деньги только за один этап ТЗ, а не за все ТЗ.
Стоим на стадии заключения достаточно рискового договора на разработку и внедрение достаточно серьезной и сильно кастомизированной логистической системы. Имеется старая система, которую предполагается перевести на 1С, но не создание клона, а полностью изменить архитектуру и методику работы. Старая система далеко не идеал.
Исходя из своего предыдущего опыта и тех граблей, на которые уже наступали при первичных попытках реализации этого проекта тезисно:
1. Тендер и конкурсы исключаю сразу. Трудозатратно, а плюсов мало. Предварительные проработки со всеми крупными интеграторами уже проведены. Определены два, на которых будем ориентироваться.
2. Составляем договор и делим его на два блока - составление ТЗ и разработка и внедрение решение по этому ТЗ. В договоре прописан каждый чих, т.к. впринципе интеграторы 1С не дорожат своей репутацией и 1С на это никак не влияет, следовательно легко окажемся в арбитраже. И тут должно быть все железобетонно. Я очень добрый человек, но часто наступал на грабли, поэтому доверяю только бумагам с подписями и печатями.
3. Интегратор пишет ТЗ.
4. Интегратор оценивает разработку и внедрение согласно ТЗ.
5. Если мы сошлись в цене, то начинает работы по ТЗ. Если не сошлись - работы по ТЗ начинает другой интегратор.
Встает вопрос о том, как сделать ТЗ (имею ввиду и ТЗ и техпроект).
а) оформление по ГОСТам это только оформление. Требования к содержанию совершенно поверхностные. Я могу написать ТЗ по ГОСТу, но в арбитраже Заказчик пролетит с ним как фанера над Парижем и заплатит интегратору по полной.
б) так что речь сейчас не о правилах оформления. Речь о том, как сделать ТЗ реально тем документом на основании которого внедрение может проводиться не только тем интегратором, который его разрабатывал, но также сделать его юридически полноценным.
в) N лет назад я считал, что фраза в договоре "...должно быть исчерпывающим." вполне достаточна.
г) да, мантра бОльшего числа статей этого форума заключается в том, чтобы потратить время на выстраивание доверительных отношений с подрядчиком. Ну ну. В арбитраже Вы как окажетесь - увидите как спалились все Ваши так долго выстраиваемые доверительные отношения в одну секунду всего из-за каких-то там 500 тысяч, по которым почему-то не удалось договориться.
д) как юридически грамотно оформить договор и ТЗ я знаю.
Это все была прелюдия. Теперь собственно вопрос. Он звучит просто.
"Как в договоре обозначить (сформулировать) необходимый уровень детализации технического задания?"
Приведу пример (очень условно).
1. Первый уровень.
"ТЗ должно быть исчерпывающим."
2. Второй уровень.
"...все процессы должны быть описаны четко, лаконично, с блок-схемами, и отражать реальную специфику..."
3. Третий уровень.
"...вот тут что-то должно быть написано..."
4. Четвертый уровень.
Собственно это самый низки уровень. Самый лучший уровень. Программный код. :-)
Так вот. Как сформулировать третий уровень так, чтобы четко дать интегратору понять, что я хочу реально детального описания. А самое главное - это должна быть очень простая формулировка, которая, в случае испортившихся отношений и попыткой интегратора подсунуть фуфло со словами "Это ТЗ. Видите тут в заголовке написано ТЗ, значит это ТЗ. Подписывайте акт." однозначно трактовалось в арбитраже как фуфло.
Субъективно - такую формулировку найти невозможно, но надежда конечно есть. :)
Если не получится - составление ТЗ придется дробить на мелки блоки и интегратор будет их выполнять по очереди. Уровень детализации устраивает - подписываем акт и переходим к описанию следующего блока. Не устраивает - не подписываем акт и останавливаем работы по договору. Ищем другого интегратора. Текущий же интегратор идет в суд и получает деньги за неподписанный этап. Заказчик потерял деньги только за один этап ТЗ, а не за все ТЗ.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Сейчас речь не о технических средствах. Речь о том, как юридически сформулировать и закрепить необходимый уровень ТЗ.
Я могу написать на бумажке "Техническое Задание", нарисовать блок-схему на которой три квадратика
Производство, Склад, Клиент, которые соединены стрелочками. Это тоже ТЗ.
Как объяснить интегратору (и закрепить юридически), что мне нужен уровень детализации, который чуть чуть выше уровня программного кода.
Я могу написать на бумажке "Техническое Задание", нарисовать блок-схему на которой три квадратика
Производство, Склад, Клиент, которые соединены стрелочками. Это тоже ТЗ.
Как объяснить интегратору (и закрепить юридически), что мне нужен уровень детализации, который чуть чуть выше уровня программного кода.
(5) Да, времени и денег потрачено будет много, но этим мы минимизируем риски. На самом деле, откровенно, все ТЗ, которые я видел вживую и в открытом доступе - это поверхностные описания, с которыми в случае если интегратор повернется спиной Заказчик влетает на деньги. Судья наверняка не будет заморачиваться и откажет даже в экспертизе (да да, многие думают, что экспертиза все докажет. Не будет никакой экспертизы в большинстве случаев) если Интегратор вывалит ему на стол 100 листовое ТЗ, оформленное по ГОСТам. Он скажет оплатить работы Интегратора и не будет слушать доводы Заказчика о том, что это ТЗ по сути просто куча правильно оформленных бумаг, которые нельзя передать другому интегратору для работы по разработке и внедрению.
Один из выходов - юридически прописать в договоре взаимосвязь вознаграждения\оплаты за конкретные результаты (достижения целей). К примеру: снижение уровня затрат операционного времени на 10%. При этом методика получения этого показателя тоже должны быть точно описана в приложении к договору.
Тогда (если вы способны будете закрепить именно такие показатели, которые соотвествуют вашим реальным целям автоматизации) у вас будет полная страхзовка от рисков "нессотвествия".
Но в этом подходе тоже есть риски))
Глобально их два:
1. Несопосбность заказчика установить\закрепить правильные показатели, соотвествующие целям (или их неточное попапдание в цели).
2. Найти исполнителя, который согласится рабоать на таких условиях ("отвечает за базар"))).
На самом деле болтологи интеграторов, руководители их подразделений и продажники будут на каждом, а сообенно предварительных этапах, уверять вас о обязательном: снижении уровня затрат, пересортиц на складе, потерь рабочего времени, увеличении объема продаж, прибыли, сокращении персонала, стабильности и прочих плюшках. Но как только вы скажете волшебные фразы:
"А вы гарантируете рост продаж и сокращение рабочего времени? А давайте закрепим это юридически?" - сразу они все где-то "потеряются"))) (так как за свои слова в сфере 1с, особенно, на удивление, крупных интеграторов, никто не отвечает... увы).
Тогда (если вы способны будете закрепить именно такие показатели, которые соотвествуют вашим реальным целям автоматизации) у вас будет полная страхзовка от рисков "нессотвествия".
Но в этом подходе тоже есть риски))
Глобально их два:
1. Несопосбность заказчика установить\закрепить правильные показатели, соотвествующие целям (или их неточное попапдание в цели).
2. Найти исполнителя, который согласится рабоать на таких условиях ("отвечает за базар"))).
На самом деле болтологи интеграторов, руководители их подразделений и продажники будут на каждом, а сообенно предварительных этапах, уверять вас о обязательном: снижении уровня затрат, пересортиц на складе, потерь рабочего времени, увеличении объема продаж, прибыли, сокращении персонала, стабильности и прочих плюшках. Но как только вы скажете волшебные фразы:
"А вы гарантируете рост продаж и сокращение рабочего времени? А давайте закрепим это юридически?" - сразу они все где-то "потеряются"))) (так как за свои слова в сфере 1с, особенно, на удивление, крупных интеграторов, никто не отвечает... увы).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот