Текст книги "Франчайзи на грани нервного срыва. Как небольшой фирме-партнеру 1С перестать выживать и начать зарабатывать"
Автор книги: Рустэм Валеев
Жанр: Маркетинг; PR; реклама, Бизнес-Книги
Возрастные ограничения: +16
сообщить о неприемлемом содержимом
Текущая страница: 18 (всего у книги 19 страниц)
Глава 40. Как провалить несколько тендеров из-за пустяков
Мы стали участвовать в тендерах прямо с того момента, как они появились. Сперва их было немного, но с каждым годом становилось все больше. Крупные заказчики создавали закупочные комиссии, писали положения о закупках и подключались к электронным площадкам. С тех пор мы приняли участие в сотнях закупок, и накопили достаточный опыт провалов. Некоторые провалы случались из-за сущих пустяков.
Автодор объявил тендер на внедрение ERP-системы. Мы активно готовились к участию. Внимательно изучили документацию. Заполнили два десятка форм. Подключились к электронной площадке для торгов. Выложить свое предложение решили в последний день, в пятницу. В понедельник я внимательно изучил протокол о вскрытии конвертов на площадке. Но не обнаружил там нашей компании. Выяснилось, что руководитель подразделения дал распоряжение помощнице выложить наше предложение, когда до закрытия торгов оставалось 10 минут. Увы, именно в эти 10 минут произошел сбой. Компьютер не включился – сгорел блок питания. Времени на то, чтобы заменить его на рабочий, уже не оставалось. Цена вопроса – 20 миллионов рублей. Они достались нашему конкуренту, небольшой местной фирме-франчайзи.
Водоканал проводил тендер на внедрение программы «1С: Управление водоканалом». Мы подстраховались, и решили выкладываться за день до закрытия торгов. Но, к сожалению, выложить готовые документы мы не смогли. Выяснилось, что не оплачена торговая площадка. Процессы выписки счета, его согласования, оплаты, регистрации платежа и включение доступа на площадку заняли два дня. Заказчику пришлось отменять закупку и запускать процедуру по новой. Деньги мы не потеряли, на нас просто поругались. Было очень неприятно.
Теплосеть объявила тендер на сопровождение системы «1С: Управление теплосетью 2». Серьезный заказчик, работать надо год по строгому SLA, цена вопроса – 14 миллионов рублей. Я уже отошел от личной проверки тендерной документации, доверился руководителю отдела продаж. Она последовала моему примеру и доверилась помощнице. Помощница доверилась нашему опыту и заполнила одну из форм, скопировав содержание из предыдущего тендера.
В результате объем наших контрактов по интересующему заказчика направлению был уменьшен в 1 000 раз. В предыдущей таблице использовались единицы измерения «тыс. руб». А в новой – «руб.». Наша заявка была отклонена по формальным признакам. Нас посчитали подрядчиком, не имеющим соответствующего опыта. Нам повезло, и заявку нашего конкурента также отклонили из-за неверно заполненных форм. Мне позвонил один из стейкхолдеров заказчика. Он не ожидал такого низкого уровня работы с тендерной документацией в серьезной фирме. Я молча слушал, возразить было нечего. Закупку заказчик повторил только через полгода. Все это время мы висели в воздухе.
Это была последняя капля. Я сел и задумался, что мы можем сделать, чтобы избежать таких провалов в будущем. Посоветовался с партнером, Ольгой.
– Так все просто. Если вы хотите, чтобы тендеры не проваливались из-за пустяков, сделайте чек-лист. И начинайте заполнять его в тот день, как узнаете о тендере.
– Слушай, а это идея. Хватит уже наступать на одни и те же грабли!
Мы собрались с руководителями отделов продаж и разработали такой чек-лист. В шапку поместили общую информацию о тендере и формулы для вычисления критических дат. В списке операций описали последовательность действий. Помощник должен будет отмечать дату, когда операция выполнена. Самое главное – прямо в чек-листе мы перечислили риски. Что может быть, если не выполнить проверку или операцию? Описание помогало сотруднику понять возможные последствия и повысить ответственность.
Вот перечень рисков, которые позволяет контролировать наш чек-лист:
– Если не рассчитать все даты заранее, можно что-то не успеть сделать в срок и провалить тендер.
– Если руководитель, ознакомившись с тендером, решит не участвовать в нем, можно потратить время впустую на подготовку документов.
– Если подписать невыполнимый или невыгодный договор, компания может понести финансовые потери.
– Если победить в тендере и не подписать договор – компания окажется в списке недобросовестных поставщиков на 2 года.
– Если победить в тендере и не отгрузить клиенту лицензии из-за того, что «1С» не дала разрешение – компания окажется в списке недобросовестных поставщиков на 2 года.
– Если не аккредитоваться и не оплатить тендерную площадку до даты выкладки документов, можно не успеть выложиться в срок и провалить тендер.
– Если не предоставить обеспечение в срок, клиент отклонит компанию по формальным признакам, и тендер будет провален.
– Если директора не будет на месте в день подписания документов, можно не успеть выложиться в срок и провалить тендер.
– Если упустить какой-то документ или заполнить его неверно, клиент отклонит компанию по формальным признакам, и тендер будет провален.
– Если сайт площадки или компьютер, или программы, или ключи не будут работать в дату выкладки, мы не сможем принять участие в тендере.
– Если не подписать договор поставки в срок и не выполнить поставку в срок, компания окажется в списке недобросовестных поставщиков на 2 года.
– Если не отслеживать возврат обеспечения, клиент может «забыть» его вернуть и компания понесет финансовые потери.
Чек-лист используется при подготовке каждого тендера на сумму свыше 500 тысяч рублей. Помощник сначала заполняет шапку документа и вычисляет все критические даты. После этого согласовывает с непосредственным руководителем целесообразность участия в тендере. Руководитель, прежде чем принять такое решение, анализирует требования к поставщику и текст договора. Если решение об участии принято, помощник ставит директора в известность о дате подписания документов. После чего организует доступ на площадку и оплату обеспечения, в том числе предоставление банковской гарантии. Получает, при необходимости, разрешение на поставку от фирмы «1С». Готовит и тщательно проверяет документацию. Заранее выкладывает предложение на площадку, чтобы защититься от компьютерного сбоя.
Для того чтобы избежать неверного заполнения документов, мы предусмотрели двойную проверку. Результаты проверки отражаются в реестре документов, который прикладывается к чек-листу.
Остается добавить только одно. С момента внедрения чек-листа не случилось ни одного сбоя в тендерах, в которых мы приняли участие.
Ниже приведен шаблон чек-листа.
Чек-лист на тендер
Глава 42. Как выиграть тендер на услуги
Мы проиграли тендер на 2 миллиона рублей. У крупного заказчика, с которым работаем много лет. И с которым совместно подготовили документацию к тендеру. В том числе техническое задание на проект доработки к программам, разработанным и внедренным нами у заказчика. Как же такое могло получиться?
Тендер взяла конкурирующая фирма-франчайзи. Благодаря цене на четверть ниже нашей. Заказчик мог бы избежать тендера, назначив нас единственным поставщиком. Но этому помешала позиция службы безопасности. Серьезные ребята, стоящие на страже интересов компании в целом. Для них важно, чтобы не было сговора между специалистами заказчика и подрядчика. Что является лучшим доказательством того, что такого сговора нет? Правильно, периодическая смена подрядчика. При работе с единственным поставщиком такое невозможно. Поэтому случился тендер. Определенный вклад внесла и служба закупки. Что важно для них? Чтобы цена была как можно ниже. Как они добиваются такого результата? Просто: обзванивают всех подходящих подрядчиков и приглашают их на тендер. Поэтому в тендере принял участие подрядчик, костяк которого составляли студенты. Безопасники и закупщики были довольны – они добились своего.
Новый подрядчик, как выяснилось позже, не имел достаточного опыта подготовки проектной документации. В итоге всю сделанную по проекту документацию заказчик завернул с замечаниями. Сроки были сорваны. Таким образом, заказавшее разработку бизнес-подразделение и ИТ-служба заказчика проиграли от смены подрядчика.
Заказчик сделал правильные выводы, и в следующий тендер этот подрядчик не попал. О том, что именно было сделано, я расскажу чуть позже. А сейчас мы поговорим об определенной классификации тендеров по предмету закупки и отношению заказчика. И детально разберем алгоритмы победы в каждом из видов конкурсов.
Итак, введем следующую классификацию тендеров:
1. Заказчик «не шел на контакт» до тендера, он хочет «не вас».
2. Вы консультировали заказчика, и заказчик хочет «вас» (хотя некоторые службы заказчика хотят совсем другого).
3. Заказчик самостоятельно готовил тендер и хочет только «минимальную цену».
4. Заказчик самостоятельно готовил тендер и хочет «лучшее предложение от подходящего подрядчика».
И разберем каждый из видов.
1. Заказчик не шел на контакт до тендера, он хочет «не вас»
Мы в таких тендерах не участвуем и, значит, не можем проиграть. Для нас самое главное – правильно распознать такой тендер. Первый индикатор очевиден – «заказчик не шел на контакт». Но как распознать – хочет он вас или нет? Тендер, в котором заказчик уже выбрал другого партнера, легко спутать с другими видами тендеров – «на понижение цены» и «на выбор лучшего предложения». Тут нельзя полагаться на приглашение от службы закупки. Мы понимаем, что они не являются настоящими заказчиками. Задача этих ребят – нагнать толпу и снизить цену. Поэтому мы внимательно смотрим на критерии отбора. Экзотические требования – такие, как «18 сертифицированных специалистов по подсистеме МСФО», «наличие трехлетнего опыта внедрения программы неизвестного разработчика» или «наличие офиса в собственности в центре мегаполиса» – включают красную лампочку. И, конечно же, мы общаемся со службой ИТ, если все же удается выйти на контакт. Порядочные ребята сразу говорят, что нам «не рады». Осторожные «мычат» что-то невразумительное. Но мы понимаем это мычание и дальше не лезем.
Но если мы говорим о победе, то и такой тендер можно взять. Прежде всего? низкой ценой. А также созданием консорциума с партнерами для соответствия экзотическим требованиям. Даже если придется искать нескольких, чтобы набрать 18 сертификатов МСФО. Однако такой договор невозможно выполнить. Если заказчик вас «не хочет», он создаст вам адские условия и не позволит сдать работу. Вряд ли вы подпишете хотя бы один акт. Скорее всего, вы просто загремите в список недобросовестных поставщиков. Если вы случайно, по ошибке или неосторожности, победили в таком тендере, у вас есть единственный шанс соскочить: попробуйте договориться с заказчиком о расторжении договора без взаимных претензий. Иногда это удается.
Приведу пример такого тендера из своей практики. Местный колхоз решил внедрять ERP-систему. Мы провели обследование, подготовили предложение. Но главный бухгалтер заказчика давно сотрудничала с другим партнером «1С», поэтому в тендере появилось экзотическое требование: «иметь офис в собственности в Уфе». Мы звоночка не услышали, лампочку красную не разглядели. Нас отклонили как не соответствующих требованиям. Глухие и слепые, мы продолжали грызть кактус. Подали жалобу в ФАС. Тендер признали недействительным. Чего мы добились? Ничего, просто потратили время. Заказчик не стал повторять тендер на внедрение ERP. Нашел другой способ работать с конкурентом.
2. Вы консультировали заказчика, и заказчик хочет «вас» (хотя некоторые службы заказчика хотят совсем другого)
По моему мнению, разумные заказчики выбирают подрядчика заранее, до тендера. Тендером разумный заказчик просто оформляет результаты выбора. Этот мой тезис не противоречит законам – ни 223-ФЗ, ни 44-ФЗ. Все должно быть законно. И закон позволяет установить разумные критерии для отбора поставщика, включающие требования к его опыту и статусам. И если заказчик вас выбрал, он сможет установить такие критерии, которым вы будете соответствовать. При этом ИТ-служба заказчика сумеет донести эти разумные требования и до службы безопасности, и до службы закупок.
Какие требования могут обеспечить защиту тендера от неподходящих поставщиков, а также убедят безопасников и закупщиков? Прежде всего, это ваши статусы в фирме «1С». Ниже перечислены статусы, на которые опираются заказчики при отборе подрядчиков:
● Центр компетенции 1C: КОРП;
● 1С: Центр компетенции (по ERP-решениям, документообороту, торговым, бюджетным решениям и прочие);
● 1С: Центр корпоративной технологической поддержки;
● 1С: Центр разработки.
Далее идут требования к наличию в штате определенного количества подходящих сотрудников. Сертифицированных руководителей проектов 1С, экспертов, специалистов, профессионалов. Но разумные заказчики не ограничиваются требованиями к сертификатам от фирмы «1С». В практике встречаются требования иметь в своем штате специалистов с сертификатами «Профессиональный бухгалтер», «Project Management Professional (PMP)» и другими. Также в требованиях к специалистам могут указать наличие определенного и документально подтвержденного опыта. Например, опыта разработки методологии юридически значимого документооборота или учета по МСФО.
И, наконец, надежно защищают тендер требования к наличию у подрядчика специфического, отраслевого или функционального опыта. Обычно его выражают в сумме выполненных договоров за определенный срок или в количестве официальных писем-отзывов. Если ваша компания имеет отраслевую или функциональную специализацию, вы выгодно отличаетесь от, так скажем, всеядных коллег.
Конечно же, разумные заказчики не будут устанавливать такие критерии, которым соответствует только ваша фирма. В конкурсе должны принять участие и конкуренты, иначе есть риск, что он не состоится. Победите вы только в том случае, если система подсчета баллов правильно учтет ваши статусы, специалистов и опыт.
В примере, который я приводил в начале главы, ИТ-отдел заказчика добавил несколько требований к очередному конкурсу, которые были с пониманием приняты службами безопасности и закупок. Теперь подрядчик должен иметь действующий статус 1С: Центра разработки, а также опыт разработки и внедрения отраслевых программ, установленных у заказчика. С такими требованиями демпинговые цены уже не помогут нашему местному конкуренту.
3. Заказчик самостоятельно готовил тендер и хочет только «минимальную цену»
Этот тендер не стоит путать с тем, в котором заказчик заранее выбрал «не вас». Документация на тендеры с минимальной ценой не содержит экзотических критериев и вообще хоть каких-то критериев, снижающих конкуренцию. А директор по ИТ приглашает вас к участию с энтузиазмом и удовольствием. Единственный способ победы на таком тендере – снижение цены. Так делают либо совсем небольшие фирмы с низкой себестоимостью работ, либо крупные, ориентированные на массовый рынок.
В крупных фирмах, прежде чем принять решение взять такой тендер, учитывают еще два фактора. Первый – юридическая безопасность договора. Фирмы проверяют, смогут ли они «соскочить», если что-то пойдет «не так». В частности, проверяется величина штрафов. Частенько заказчик не ограничивает свои аппетиты суммой договора и грозит взыскать убытки. Второй фактор – возможность увеличить сумму после уточнения требований заказчика. Обычно положение о закупках заказчика позволяет увеличивать сумму договора до 30 % без проведения повторного тендера.
Мы не участвуем в таких тендерах по следующей причине. Мы считаем высокую цену договора серьезным фактором, повышающим вероятность его успешного завершения. Вспомним, что говорит нам о провальных проектах классическая книга Эдварда Йордана «Путь камикадзе»:
«Под безнадежным проектом (death march) я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50 %. По отношению к софтверным проектам это означает одно или более из следующих ограничений… […] 3) Бюджет и связанные с ним ресурсы урезаны наполовину. […] это может быть и результатом конкурентной борьбы за выгодный контракт».
Тезис Йордана полностью совпадают с моим мнением, сложившимся за годы участия в тендерах. Заказчики, стремящиеся к самой низкой цене, создают безнадежные проекты. Прежде всего они назначают НМЦК (начальную максимальную цену контракта) как наименьшую из предложенных подрядчиками цен. После чего устраивают «бойню» по цене между большим количеством конкурентов. В результате бюджет проекта неизбежно снижается до значений, которые делают его безнадежным.
Вот небольшой пример тендера, выигранного по цене. Завод в одном из регионов страны подал на подрядчика в суд через год после начала работы. Обоснование иска: «мы за свои деньги хотели получить внедренную систему». Подрядчик же был уверен, что с лихвой отработал заплаченные деньги и не собирался удовлетворять возросшие требования заказчика в рамках фиксированного бюджета. В итоге суд решил, что договор выполнен не полностью, и взыскал с подрядчика свыше 400 тысяч рублей из полученных ранее. Подрядчику повезло, так как общая сумма иска составляла более 2 миллионов рублей. На хождение по инстанциям стороны потратили два года.
4. Заказчик самостоятельно готовил тендер и хочет «лучшее предложение от подходящего подрядчика»
Вот мы и подошли к самым интересным тендерам, участие в которых способно прокачать когнитивные способности подрядчика на 100 %. Как же распознать такой тендер? Прежде всего, по требованиям к подрядчикам. Очевидно, что они ограничивают конкуренцию, не допуская к конкурсу всех подряд. Требования к статусам, специалистам и опыту допускают на конкурс только подрядчиков, способных выполнить проект. Бюджет проекта – достойный, который рассчитан заказчиком по внутренней методике или на основании предложений квалифицированных подрядчиков. При общении с ИТ-службой выясняется, что конкурс – честный. И, наконец, вы можете легко вычислить подходящих под требования конкурентов.
Такой тендер, безусловно, можно выиграть, тщательно подготовив документацию, подтверждающую ваши компетенции. Однако цену все же придется снизить. На сколько именно снижать цену? Прежде всего, нужно понять, какую оценку в баллах получит ваше предложение. Как именно будут считаться баллы, указано в конкурсной документации. После этого нужно постараться вычислить эти баллы для ваших конкурентов. А также сделать допущение о том, на сколько они будут готовы снизить цену. Тут не обойтись без конкурентной разведки. Придется изучить другие тендеры, в которых принимали участие ваши конкуренты. И, наконец, вам нужно знать цену, до которой вы готовы «падать».
Сразу хочу сказать, что попытки договориться с конкурентами – не только незаконны, но и ничего не дадут. Конкурент, которому вы позвоните, может даже сказать, что согласился бы, если бы вы знали всех конкурентов и уговорили бы каждого. Поэтому действовать придется исходя из гипотез о баллах конкурентов, об их поведении в части цены и вашей нижней планки по цене.
Приведу пример такого тендера, в котором победила наша компания. Крупная теплосеть, с которой мы сотрудничали больше года, прямо заявила, что хочет снижения текущей цены. Но только в том случае, если в конкурсе примут участие подходящие исполнители. Специалисты заказчика так сформулировали требования к подрядчикам, что в конкурсе приняли участие всего три компании. Наши конкуренты даже заявили чужих специалистов, чтобы обеспечить соответствие. Мы же, понимая, что по квалификационным требованиям наберем максимальное количество баллов, снизили цены на услуги на 20 % и уверенно победили в конкурсе. Такое снижение стало возможным из-за перехода на удаленный формат работы без выездов в командировки. Самый опасный конкурент дал цену ниже на 40 %. Как выяснилось позже, мы перестраховались, и даже 10-процентное снижение цены позволило бы нам победить. Поэтому мы внесли в наш чек-лист для тендеров специальные разделы «Список возможных конкурентов» и «Расчет наших баллов и баллов конкурентов». Такие расчеты позволят нам принимать более взвешенные решения и не терять так много в деньгах.
Глава 43. Как заключить правильный договор на внедрение
История эта произошла не со мной, с другим партнером «1С». Но я принял ее близко к сердцу.
2005 год. Молодая, но быстро развивающаяся фирма-франчайзи заключила договор с буровой компанией. На внедрение программы 1С: УПП, которая только вышла. Всех ее подсистем. Управление производством, сбытом, снабжением, кадровый и регламентированный учет, расчет зарплаты, в общем – все. Под ключ, на три миллиона рублей. До этого фирма заключала договора на десятки и сотни тысяч рублей, и три миллиона им казались бесконечной суммой, которой хватит на все. Даже если что-то пойдет не так, миллионы покроют все риски. Владелец фирмы уже присматривал себе новую квартиру. Или даже дом, такая высокая прибыль ожидалась.
Фирма получила предоплату и приступила к работе. Прошло полгода. Срок договора заканчивался, но программа все еще не была внедрена. Заказчик выдвигал все новые и новые требования, и никак не подписывал акт. Деньги заканчивались. Директор был вынужден урезать зарплату вдвое. Пара специалистов уволилась. Остальные затянули ремни потуже, но продолжали работать. Ответственные, порядочные ребята. Работы было так много, что директор решил на время отказаться от других договоров. Чтобы не отвлекаться и побыстрее автоматизировать буровиков. Прошло еще три месяца. Деньги кончились совсем, и фирма не смогла выплатить зарплату. В итоге все сотрудники разбежались, а акт так и не был подписан.
Мой партнер, который рассказал мне эту историю, спросил, а что бы я сделал в такой ситуации?
– Я бы увеличил сумму договора. Помнишь наш разговор с директором тепловозоремонтного завода?
– Помню, конечно. Он вам сказал: «Представьте, что вы пришли в булочную. Взяли батон за 20 рублей. Пока шли к кассе, цена поднялась до 40».
– А помнишь, что я ему ответил? «Я – не пекарь, я – бывший строитель. Представьте, что вы заказали построить новый цех. Пока строился фундамент, выяснилось, что вам нужно не два, а три этажа. И перегородки, чтобы отделить комнату мастера. Останется ли цена прежней?»
Эту историю я вспомнил в кафе, где мы встретились с директором ИТ крупного холдинга. Мы обсуждали проблемы, которые возникли на нашем договоре по внедрению 1С: ERP на одном из заводов. Ситуация могла выйти из-под контроля в самое ближайшее время. Перед заключением договора было проведено предпроектное обследование. Выявлены требования стейкхолдеров, требующие значительных доработок типовой программы. Определен примерный бюджет проекта. Заключен договор, в котором установлен следующий порядок выполнения и приемки работ. На каждую доработку разрабатывалось подробное техническое решение, после чего давалась точная оценка ее трудоемкости. По трудоемкости определялся перечень доработок в бюджете текущего месяца. После того, как доработки принимались комиссией, ежемесячно подписывался акт выполненных работ. Мы проработали по такой схеме три месяца, когда стало ясно, что бюджета проекта может и не хватить на все доработки. Руслан Анварович хотел избежать ситуации, когда деньги кончатся раньше, чем пожелания.
– Вчера меня вызывали в проектный офис. Рассматривали статус-отчет по нашему проекту. Говорили о рисках не уложиться в бюджет. Понимаешь, у нас в холдинге жесткая политика – все договора выполнять по технологии «ватерфолл»[43]43
Ватерфолл или Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
[Закрыть]. Проект, оценка, твердая цена. Не уложился в бюджет или в срок – давай, до свидания. Мы должны переписать наш договор. Когда мы его заключали, я ошибся, и в договоре у нас получился чистый «эджайл».
– Но у нас другая ситуация. Детальный технический проект мы не делали, делали только предпроектное обследование. В нашем договоре прямо написано, что бюджет – примерный, и что мы уточним его по мере уточнения требований. Потом – у нас есть очень важный стейкхолдер, директор по производству. Раньше он работал на заводе, где была внедрена APS-система[44]44
APS (сокр. от англ. Advanced Planning & Scheduling – усовершенствованное планирование) – программное обеспечение для производственного планирования, главной особенностью которого является возможность построения расписания работы оборудования в рамках всего предприятия.
[Закрыть]. У нас, как вы знаете, ERP. Сейчас мы ERP переписываем так, чтобы учесть все его пожелания. Учимся размещать новые заказы в сверстанную производственную программу с учетом загрузки оборудования. Но это не все. На днях к нему подключился финансовый директор. Он хочет, чтобы мы не забыли про то, как у вас работает старая система сейчас. Нам нужно реализовать систему «канбан»[45]45
Канбан (яп. Камбан) – система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».
[Закрыть]. Запускать в производство только те полуфабрикаты, которые нужны для выпуска конкретной продукции. Тут без эджайла нам никак не обойтись.
– Понимаю, что у вас тоже риски. Мы можем увеличить общую сумму договора на 10 %, чтобы их учесть. Но цена должна стать твердой.
– Если бы я был уверен, что разработка новых уникальных подсистем покроется этой суммой, я бы согласился. Но я, к сожалению, не уверен. Будем изо всех сил стараться уложиться в бюджет, но договор мы менять не будем. Он соответствует тому процессу, который сейчас происходит на проекте.
Руслан Анварович расстроился, пытался уговорить меня, даже повысил голос. Мне было очень трудно выдержать такое давление, но я не сдался.
За десятки лет работы в ИТ в качестве подрядчиков мои компании не получили ни одного иска со стороны заказчиков. Мы всегда выполняем взятые на себя обязательства. Не только потому, что мы хорошие подрядчики. Но и потому, что мы составляем правильные договоры. Договоры, позволяющие учитывать множество рисков, возникающих при их выполнении.
Рисков, которые могут привести к срыву сроков проекта, его невыполнению или убыткам на стороне подрядчика, довольно много. Но все их можно отнести к трем большим группам.
1. Увеличение требований заказчика без соответствующего увеличения бюджета и сроков проекта.
Такое увеличение может происходить по множеству причин. Наиболее частые случаи следующие:
● плохая фиксация границ проекта, в том числе отсутствие перечисления автоматизируемых подразделений и бизнес-процессов заказчика (плохой пример – «автоматизация управленческого учета в полном объеме»);
● плохое прояснение требований до начала проекта, отказ от предпроектного обследования, отсутствие технического задания или технического проекта («мы не будем платить за обследование, зачем нам этот отчет, мы и так знаем, что хотим»);
● появление новых стейкхолдеров по ходу проекта («а теперь согласуем это с Иваном Петровичем, его вчера назначили директором по сбыту»);
● плохое прояснение очевидных для заказчика требований, выполнение которых он ожидает получить «по умолчанию», например, требований отраслевых нормативных документов («ну вы же эксперты в нашей отрасли, вы должны были это предусмотреть и нас предупредить»);
● Требование переделать интерфейс или бизнес-процесс в типовой программе под привычные для пользователей («мне теперь приходится открывать три окошка, я не могу так работать»).
2. Невыполнение заказчиком своей части обязательств по договору.
Не каждый заказчик и не всегда понимает, что внедрение новой программы – это совместная деятельность объединенной команды, в которую входят как представители подрядчика, так и представители заказчика. А значит, и успех проекта зависит не только от подрядчика. Но и от того, как сработают члены команды со стороны заказчика.
В нашей практике встречались:
● непредоставление заказчиком требуемой для выполнения работы инфраструктуры; отсутствовала локальная сеть, не могли выделить рабочий стол для консультанта, не покупали вовремя сервер;
● отсутствие необходимого уровня доступа к программам и локальной сети; служба безопасности заказчика затягивала с предоставлением такого доступа;
● непредоставление или несвоевременное предоставление нужной информации: бывало, что мы неделями не могли получить копии нужных приказов, или у ключевого пользователя никак не находилось времени на общение с бизнес-аналитиком;
● невыполнение решений производственных совещаний на стороне заказчика; частенько пользователи не вносят вовремя нужную информацию в новую систему и не сверяют полученные результаты.
3. Отказ заказчика от приемки и оплаты выполненных работ.
Думаю, каждый встречался со следующими ситуациями:
● ключевой специалист заказчика – «в отпуске» («на больничном», «уволился»), «скоро ему найдут замену» (или «он вернется»), «все проверит, акт подпишут и счет оплатят»;
● заказчик высказал устные замечания и ждет их устранения, чтобы подписать акт;
● заказчик дал только часть замечаний, а после того как они были устранены, – выдвинул новые;
● акт у заказчика подписал человек без должных полномочий, поэтому акт недействительный и не будет оплачен;
● заказчик потерял акт выполненных работ или счет, просит подготовить новые документы;
● заказчик еще «не выплатил зарплату» («долги за свет» или «за газ»), «скоро он рассчитается с сотрудниками и подойдет ваша очередь».
Для того чтобы снизить такие риски, есть два пути. Первый состоит в том, чтобы правильно выбрать структуру и тип договоров при заключении. Второй – в том, чтобы внести в текст каждого договора специальные условия.
1. Выбор правильной структуры и типа договора.
Управление проектом на уровне структуры и типов договоров лучше всего позволяет избежать риска увеличения требований без увеличения бюджета договора. Рассмотрим возможные подходы.
1.1. Отдельный договор – на внедрение, отдельный – на доработки. В основном договоре специально оговаривается, что «внедряется типовое решение без доработок». Если возникает необходимость в доработках, заключается договор на доработки с фиксированной ценой часа, но без указания объема доработок. Каждая доработка оценивается отдельно и выполняется после получения предоплаты за нее по отдельному счету.
1.2. Отдельный договор – на проект, отдельный – на внедрение. По первому договору разрабатывается подробный технический проект. Он включает в себя функциональную и информационную модели новой системы, набор интерфейсов, печатных форм и отчетов. По его результатам с достаточной точностью оцениваются объем доработок и стоимость услуг по внедрению. После чего заключается второй договор. Оба договора – с фиксированной ценой, но цена второго определяется только после выполнения первого.
1.3. Отдельный договор – на пилотный проект, отдельный – на тиражирование. В результате удается более правильно распределить бюджет проекта, направив основную часть на трудоемкую разработку пилота. Тиражирование готовой системы проходит легче, чем одновременное ее внедрение на всех рабочих местах. Практика широко применяется в холдингах или на предприятиях с ярко выраженной продуктовой структурой.
1.4. Отдельный договор – на внедрение каждой подсистемы при внедрении ERP-системы. Такой подход страхует от серьезной ошибки в оценке стоимости всех работ. Поскольку реально оценивать трудозатраты на конкретном объекте удается только с опытом.
Правообладателям!
Это произведение, предположительно, находится в статусе 'public domain'. Если это не так и размещение материала нарушает чьи-либо права, то сообщите нам об этом.