Фамилии исполнителей в договоре между клиентом и внедренцем

[Lz_]

Цитата:

Сообщение от kosenkov

А в чем дилетантизм-то? Разные же могут быть условия оплаты по договору. В том числе и включающие предоплату

Цитата:

Сообщение от ice

точно точно, а вот на гос контрактах там исполнитель еще обеспечение заявки и обеспечение исполнения контракта сам должен заплатить

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

Цитата:

Сообщение от lev

В таких условиях, как мне кажется, даже идеально составленная проектная документация, не поможет. Не зная целей и задач, которые стоят перед бизнесом, не получится провести адекватного внедрения. Потому, что, у руководителей бизнес подразделений будут постоянно появляться новые идеи, старые идеи буду изменяться или вообще "удаляться", а вместо них появляться другие. В таком хаосе, адекватного проекта быть не может.

Согласен. Очень тяжело сделать качественную систему, если цели постоянно меняются.

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

Цитата:

Сообщение от dmitryul

Я говорю про внедрение в коммерческих структурах, вы об внедрении в госсекторе.

По большому счету не должно иметь значение для коммерческой организации делаем проект или для гос. Есть хорошо организованные и управляемые организации среди частных организация и среди гос. Распил, откаты и т.п. не рассматриваем. Я о нормальном проекте.

Цитата:

Сообщение от dmitryul

Да, был пример - заказчик не указал предельный срок обследования. Сам и виноват - т.к. граничных сроков нет, подчиненные в первую очередь (а нафиг нас отвлекают!), внедренцы во-вторую (мы ходим-ходим, а всем некогда, отмахиваются, информацию из-под палки выбиваем) халявно относились к работе.

Заказчик и не должен сроки указывать, грамотное составление проектной документации, а договор это то с чего начинается проект, лежит на интеграторе. Именно интегратор является специалистом по внедрению информационных систем и знает подводные камни. Интегратор должен правильно организовать работы. Согласовать график посещений, распределить обязанности по предоставлению информации, причем не просто придя в бухгалтерию со словами: -"Мария Ивановна вам директор сказал рассказать мне о...", если нужно закрепить это приказом, проведением совещания с назначением ответственных и т.п. Таким образом на интеграторе лежит обязанность по организации работ по проекту в целом. Необходимо правильно организовать не только своих сотрудников но и сотрудников клиента. Вообще, это тема сложная и в рамках одного поста ее не раскроешь.

Цитата:

Сообщение от dmitryul

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

Жаль, что вы не ответили на поставленные мной вопросы, выша точка зрения была бы более понятна:

Цитата:

Сообщение от Lz_

ВОПРОС: Вы описываете только дополнительно создаваемые поля, кнопки формы или существующий функционал тоже описывается?
ВОПРОС: Клиент говорит: Все ок меня все устраивает, но вот эта и эта, и вон та форма дорого, платить не буду. Что делаем?
ВОПРОС: Где документация по проекту? Где инструкции пользователей и конкретных рабочих мест? Когда появляется эксплуатационная документация?

Я решительно не понимаю что вы продаете клиенту? Набор форм таблиц и кнопок с ценой по каждому пункту? Зачем клиенту информация о том, что "прикрутить" к аксе, например, справочник доверенностей стоит 3 рубля 57 коп? Что он будет с этой информацией делать?

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

Цитата:

Сообщение от dmitryul

Что такое Технический, Рабочий проект? Если я правильно понимаю, это внутренняя документация интегратора, которая к заказчику не имеет ни малейшего отношения (он за них не платит).

Посмотрите ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ.

Технический проект - это комплект документации, которая передается заказчику и в которой детально расписано как все это будет работать. Кроме того разделены функции системы между пользователями и т.д. и т.п.

Рабочая документация - грубо говоря, это комплект документации по АРМ. Инструкции, описания и т.п.

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

Цитата:

Сообщение от dmitryul

Почитайте методологию Sure Step подробно - как я понял, Вы о ней не знаете.

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

Цитата:

Сообщение от dmitryul

Понятия не имею, как в госсекторе - как я понял из Ваших слов, там на этапе ТЗ распиливаются все деньги и до внедрения не доходит.

Ничего вы из моих слов не поняли ...

Цитата:

Сообщение от dmitryul

Да каких проектов с фиксированной ценой дорасти? А я что пишу - все проекты у нас с фиксированной ценой! Стоимость рассчитывается исходя из объема работ и неизменна!

Ок. До сего дня вы как-то работали. Спорить не буду.

Цитата:

Сообщение от dmitryul

Да, по поводу обследования - а Вы считаете, что заказчик должен платит по акту сдачи?

Да. Мало того мы так и работаем Хотя, возможны варианты и с частичной предоплатой. Ну уж точно не 60% стоимости всего проекта.

Цитата:

Сообщение от dmitryul

Ну да, а Вы сами обследование хоть раз проводили? Оно может тянуться от месяца (средние предприятия, до 100 человек) до года (1000 человек штата). И что, интегратору забесплатно этот год работать?

Обследования проводил, на заре карьеры. Сейчас обследование как таковое не проводится. Скорее это можно назвать изучение объекта при написании ТЗ. К тому же часто сталкиваемся с ситуацией, когда у клиента в принципе отстутствуют некоторые бизнес-процессы, поскольку старая система или методы работы строились совсем по-другому. Например, у клиента был обычный склад, адресного хранения не было. Теперь клиент "дорос" до необходимости использования адресных складов + терминалы + и т.д. Что тут обследовать? У клиента все процессы остались: приемка, отгрузка, инвентаризация. Только выполняться процессы будут по-другому. Зачем тратить время на обследование старых процессов, если они в принципе видоизменятся? Не лучше ли сосредоточить силы на изучение того, как надо что бы это работало?

Цитата:

Сообщение от dmitryul

В договоре на обследование (анализ) указывается конкретно предельное количество часов, затраченных на обследование (например, по отделам) и его стоимость. В госструктурах обычно идет 60% предоплата на все проекты сразу, потом по закрытию этапов.

Так вы все таки продаете клиенту услуги, выраженные в часах? Клиент результаты обследования может вернуть на доработку из-за ошибок, непоняток, недоработок? Клиент дополнительно оплачивает часы затарченные на доработку документа?

Цитата:

Сообщение от lev

в общем получается, что НЕ удачное завершение проекта состоит из многих отрицательных факторов. И НЕ грамотное составление проектной-документации далеко не основной фактор

Грамотное составление документации позволяет уменьшить риски и влияние некоторых факторов. Безусловно, это не панацея.

Есть еще один момент, но скорее всего он не характерен для РФ, по крайней мере пока. У нас в РБ есть такой орган - Госконтроль, наверное аналог вашей Счетной палаты. Только у этого "органа глубокого бурения" есть полномочия не только проверять и штрафы выписывать, но и реально посадить могут. Так что, грамотно составленная документация помогает не только уменьшить риски проекта, но и, извините, зад***у прикрыть, в случае чего.

Цитата:

Сообщение от Ivanhoe

А про вину стажеров (топик) уже и забыли?

А стажеров никто не обвинял. Так что вины у стажеров никакой нет.
Правда, я немножко увел тему в сторону документации .