Выбор продавца

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

Мы продолжали искать других продавцов с "нужной" платформой аппаратных средств, но, наконец, пришли к выводу, что остальные не могли продемонстрировать необходимую функциональность ПО. Наконец, выбранный нами первоначально продавец, предложил адаптировать свою систему для открытой (UNIX) системы на IBM RS/6000. Это означало компромисс со стороны нашего продавца, и руководство, наконец-то, одобрило осуществление нашего проекта.

Подписание договора с продавцом

Эйфория после получения одобрения руководства корпорации длилась недолго; ведь нам еще нужно было подписать договор с нашим продавцом, чтобы реальная работа над нашей системой могла начаться. После того, как мы так внимательно работали над критериями ранжирования продавцом, мы не могли легкомысленно или в спешке подписать договор только для того, чтобы могло начаться проектирование нашей системы.

Мы не только добились того, чтобы фиксированные цены или предельно допустимые цены за систему были включены в договор, мы также позаботились о том, как и когда будут выплачиваться деньги. Последним средством воздействия на нашего продавца у нас стало одобрение платежа за завершение работы. Мы настояли, и наш продавец согласился, что мы не будем платить, пока:

1. Не наступит согласованная дата промежуточного этапа выполнения работ.

2. Работа на конкретном промежуточном этапе не будет завершена к удовлетворению «Rubbermaid».

3. Промежуточные этапы не завершаются в последовательном порядке. Иначе говоря, продавец не может пропустить один промежуточный этап и завершить другой.

Мы полагали, что эти меры финансово обезопасят нас в некоторых частях проекта, таких как освоение аппаратных средств, где были более высокие риски, чем в других частях проекта. Эта статья договора позднее доказала свою полезность, когда на одном из этапов разработки ПО, мы удержали платеж за следующий промежуточный этап, потому что он не был выполнен к нашему удовлетворению.

Мы не стремились создать финансовые трудности для нашего продавца, но мы платили за результаты, а не за усилия. Возможность удержать платеж, более чем что-либо еще из того, что мы пытались делать во время нашего проекта, было способно направить внимание нашего продавца на конкретные проблемы, вызывающие задержку или замедление прогресса.

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

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

Как и большинство системных интеграторов, наш продавец был небольшой компанией с меньше чем 100 работниками. Поток наличных – вот то, что помогает этим компаниям выжить. Больше денег, как правило, платят продавцу в первой половине проекта. Поэтому эти небольшие компании продолжают отдавать приоритет получению новых проектов и заказчиков.

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

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

Благодаря долгосрочному корпоративному соглашению «Rubbermaid» с компанией IBM, чего не было у нашего продавца, компания «Rubbermaid» смогла закупить аппаратные средства RS/6000 дешевле. Мы договорились о плате за интеграцию (процент от стоимости аппаратных средств) с нашим продавцом, что обеспечивало его ответственность за интеграцию аппаратных средств (включая радиотерминалы) с его ПО. Даже несмотря на плату за интеграцию, мы сэкономили деньги по сравнению с закупкой аппаратных средств через нашего системного интегратора.

В общем, мы стремились обезопасить себя в трех основных сферах:

1. Иметь фиксированные цены за разработку ПО и конфигурацию аппаратных средств. Если продавец этого предложить не может, это может указывать на его неуверенность в выполнении требований. Не оставлять цены неурегулированными до подсчета потраченных времени и материалов.

2. Платить за конкретные промежуточные этапы только когда они завершены к нашему удовлетворению, и в последовательном порядке.

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

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