Текст книги "Франчайзи на грани нервного срыва. Как небольшой фирме-партнеру 1С перестать выживать и начать зарабатывать"

1.5. Заключение отдельного договора на внедрение и отдельного – на сопровождение внедренных частей проекта. Такой подход позволяет вынести реализацию дополнительных требований, возникших по ходу проекта, за рамки его бюджета. В частности, на сопровождение передается постоянное обновление внедряемого типового решения до актуального релиза.

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

● отчет об обследовании;

● технический проект или модель будущей системы с контрольным примером;

● перечень доработок с техническими решениями по их реализации и оценкой объема;

● модель будущей системы с выполненными доработками, проверенная на сквозном контрольном примере;

● подготовленные инструкции, обученные и сертифицированные пользователи;

● система, прошедшая опытную эксплуатацию;

● система, введенная в промышленную эксплуатацию.

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

1.7. И, наконец, заключение договора по принципу «time and material», то есть без фиксации результатов, с оплатой (а еще лучше – предоплатой) потраченного времени. При этом все риски передаются заказчику или генподрядчику. В нашей практике был такой случай. Крупный интегратор заключил договор с конечным заказчиком на внедрение нашей системы «1С: Управление теплосетью 2». Нас не привлекли ни к предпроектному обследованию, ни к подготовке коммерческого предложения. Поэтому мы отказались работать по договору субподряда с фиксированной ценой и результатом. Но согласились на договор сопровождения по журналу учета времени. В итоге мы выполнили свою часть работы и получили оплату по часам за специалистов. А генподрядчик закрывал проект в целом. Он также справился со своей частью работы, благодаря большому опыту и тесным связям с заказчиком.

2. Включение в договор определенных пунктов, снижающих риски.

2.1. Примерные сроки. Вот текст, который мы включаем в договоры, которые готовим сами.

«Все сроки, указанные в настоящем договоре, являются ориентировочными в той мере, насколько эти сроки зависят от сроков предоставления информации, сроков изучения разработанной документации, сроков освоения программ и ввода необходимых данных специалистами Заказчика».

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

2.2. Указание не абсолютных, а относительных сроков. Текст в графе срок «в течение 20 рабочих дней с даты завершения работ по предыдущему этапу» намного безопаснее, чем «31.12.2020 г.». И вернее по сути, так как результаты предыдущего этапа работ используются, как правило, в следующем.

2.3. Указание конкретного объема работ в часах. Например, «доработка типового программного обеспечения в объеме, не превышающем 340 часов работы специалистов исполнителя». Такой пункт позволяет либо сокращать объем доработок до приемлемого, отказываясь от их части, либо подписывать дополнительные соглашения к договору.

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

«Плановые объемы и содержание выполняемых работ по договору приведены в Приложениях 1 и 2 к договору. Точные объемы и содержание выполняемых работ по каждому этапу определяются в «Заказах на выполнение работ» (далее по тексту – Заказы), оформляемых по форме Приложения № 3 к настоящему договору […] При формировании плановых Заказов на месяц стороны уточняют перечень и содержание работ на текущий месяц […]».

2.5. Четкое определение границ проекта. Мы добиваемся этого с помощью соответствующих приложений, в которых описываем:

● перечень автоматизируемых подразделений и рабочих мест;

● перечень автоматизируемых бизнес-процессов (функций);

● перечень внедряемых программ и их подсистем;

● перечень стейкхолдеров (ключевых пользователей).

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

2.6. Четкое определение обязательств заказчика. Вот пример этого раздела в одном из договоров:

«Заказчик обязуется:

● предоставить по предварительному письменному запросу Исполнителя необходимую информацию, организационную и техническую документацию, необходимую для оказания услуг;

● принять оказанные Исполнителем услуги согласно порядку, указанному в соответствующем разделе Договора;

● оплатить услуги Исполнителя в размере и в сроки, предусмотренные в Договоре;

● назначить приказом по предприятию:

– Руководителя проекта, обеспечивающего оперативное решение вопросов, возникающих при выполнении работ, а также ответственного за приемку выполненных работ по Актам;

– Рабочую группу, подчиненную Руководителю проекта, обеспечивающую предоставление всей информации и выполнение работ в рамках настоящего Договора;

● предоставить специалистам Исполнителя доступ к серверу базы данных и к любому из компьютеров, на которых выполняются работы;

● предоставить специалистам Исполнителя рабочие места, оборудованные столом, стулом и доступом в Интернет в случае, если работы выполняются на территории Заказчика».

2.7. Четкое определение результатов и состава работ. На рисунке приведен пример для работ на этапах контрольного примера и определения функциональных разрывов:

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

«Исполнитель не производит обучение пользователей Заказчика компьютерной грамотности».

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

2.9. Возможность приостановки выполнения работ при неоплате заказчиком какого-либо этапа по договору или в случае других нарушений. Пункт может звучать так:

«Исполнитель вправе приостановить оказание услуг и потребовать пересмотра сроков оказания услуг в случае несвоевременного исполнения Заказчиком своих обязательств по Договору и при наличии у Заказчика письменного уведомления Исполнителя о таких нарушениях и о приостановке работ».

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

2.10. Установка четкого порядка приемки работ. Обязательность предоставления замечаний к акту в письменном виде и в течение определенного времени. Условие, что при отсутствии письменных замечаний в определенный срок работы считаются принятыми заказчиком. Очевидно, что акты надо направлять только официальными письмами с уведомлением и описью содержимого.

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

● Отказ от ответственности за убытки, полученные в результате использования или невозможности использования внедряемого программного обеспечения. Аргументы – «прочитайте пользовательское соглашение фирмы Microsoft, вот где настоящий отказ от ответственности, а мы готовы ее нести в рамках российского законодательства, и не более».

● Отказ от штрафных санкций, если нет симметричной ответственности со стороны заказчика. Например, мы отказываемся от штрафа в процентах за нарушение сроков выполнения работ, если нет пункта со штрафом с таким же процентом за нарушение сроков оплаты.

● Отказ от штрафных санкций, которые могут превысить весь бюджет проекта. Ограничение штрафов до приемлемых величин в 10, максимум – 15 % от суммы договора, а еще лучше – отдельного этапа, на котором произошло нарушение. Помните, что безграничный штраф в 1 % за каждый день задержки работ способен уничтожить весь бюджет проекта всего за квартал.

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

А теперь – небольшой анекдот о том, как правильно заключать договор, если вам пришлось сильно снизить цену на тендере.

Одесское пароходство заключило договор с ООО «Рабинович и партнеры» на покраску судна. Через неделю принимают работу. Ну, вроде все сделано, как надо – пароход весь белый, красивый, в общем – как новенький… Подписали акт выполненных работ, оплатили оставшуюся сумму. Спустя некоторое время пароход отчаливает, разворачивается другим боком, а там – вся сторона ржавая, черная и без единого белого пятна.

Заказчик – в шоке, технадзор – в панике, нашли Рабиновича, привели к пароходу и говорят ему:

– Так, что за дела, почему половину работы не сделали?!

– Да что вы такое говорите? У нас все по договору! Вот, здесь же написано: ООО «Рабинович и партнеры», с одной стороны, и Одесское пароходство, с другой стороны, договорились покрасить пароход…

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

Глава 44. Как доказать, что программа внедрена, если ты – подрядчик

В ГУП[46]46
  ГУП – государственное унитарное предприятие.


[Закрыть] сменился генеральный директор. Предыдущего отправили на повышение в столицу. Новый привел своего подрядчика по ИТ, а старого выгнал. Не заплатив ему почти 2 миллиона по договору. Директор старого подрядчика был не согласен с такой постановкой вопроса. Он подал в суд на ГУП. Тогда ГУП попросил третье лицо – нового подрядчика – провести аудит проекта внедрения программы 1С. Понятно, что работа всем нужна. Поэтому аудит показал, что предыдущий подрядчик – плохой, и он «не справился» с проектом.

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

Получив материалы дела в двух томах и копию информационной базы, я приступил к работе. У меня возникло несколько вопросов к подрядчику, и я встретился с руководителем проекта. Дело в том, что документов в двух томах явно недоставало. И я пытался выяснить, не осталось ли каких-то других, не приобщенных к делу? К сожалению, таких документов не оказалось. Конечно же, мне задали вопрос, каким может быть заключение? Я не мог ответить ничего определенного, но озвучил принцип, по которому будет выполняться экспертиза. Все мои выводы должны быть обоснованы и подтверждены фактами. Если нет документов или записей в базе данных, подтверждающих факт выполнения работ, и заказчик не согласен, что работы выполнены, придется считать, что они не выполнены.

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

Мне предстояло ответить на следующий основной вопрос суда:

Вопрос.

Возможно ли корректное безошибочное функционирование программы УПП после проведенных подрядчиком работ по внедрению программного обеспечения?

Привожу ответ на вопрос суда с небольшими сокращениями, не искажающими его суть:

Ответ.

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

Пояснение.

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

1. Анализ конфигурации программы показал, что в конфигурации программы Истцом не были сделаны доработки или изменения, ухудшающие работоспособность исходного, типового программного обеспечения. Вывод – Истцом не были созданы препятствия для корректного функционирования типовой программы.

2. В деле имеются свидетельства того, что персонал Ответчика был обучен работе в программе, а также получил инструкции по такой работе. Свидетельства приведены в приложении «Расчет объемов и стоимости работ по договору». Вывод – Истец обеспечил обучение персонала Ответчика, использующего программу.

3. Текущие данные в программу, в основном, введены правильно (см. приложение «Анализ различий…»). Отсутствие части необходимых данных и частично ошибочные данные могут быть объяснены тем, что такие данные предоставляют и вводят специалисты Ответчика, а также тем, что работы Истца были прерваны по инициативе Ответчика. Вывод – Истец обеспечил условия для корректного ввода текущих данных.

4. Начальные данные (справочные данные и остатки по счетам учета) были перенесены Истцом из предыдущих программ или введены специалистами Ответчика корректно не по всем счетам (см. приложение 4 «Анализ различий…»). В деле отсутствуют документы, подтверждающие проведение сверок перенесенных (введенных) в ИБ данных с данными, представленными Ответчиком. В деле отсутствуют документы, подтверждающие приемку работ Ответчиком по этапу «Разработка конверторов для переноса начальных данных».

Суд принял отчет эксперта и обязал Ответчика оплатить Истцу стоимость выполненных работ. Обращение Ответчика по апелляции было оставлено без удовлетворения.

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

А теперь перейдем к принципам, позволяющим защитить подрядчика от недобросовестного заказчика.

Перечень принципов выполнения договора, которые снижают риски

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

1. Грамотная работа с требованиями, выходящими за рамки договора.

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

Приведу пример из своей практики. В результате выполнения этапа «контрольный пример» на одном из заводов был составлен и оценен список доработок. Объем доработок превысил сумму, заложенную на этап, в два раза. Мы хорошо подготовились к совещанию в кабинете директора. По каждой доработке описали ее содержание, привели обоснование необходимости, а также оценили последствия, если ее не делать. В итоге из 30 доработок 10 были отклонены, а 20 приняты. Бюджет этапа был увеличен в полтора раза.

2. Грамотное документирование результатов работ на каждом этапе.

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

3. Документирование запросов к заказчику.

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

4. Формирование и подписание «Окончательного списка замечаний».

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

● вопросы, требующие консультаций, в том числе дополнительные настройки программы;

● подтвержденные ошибки в программе, которые необходимо устранить;

● требования, которые были в техническом проекте (или в контрольном примере), но еще не были реализованы.

В список мы также включаем следующее пояснение:

«Этот список содержит окончательные замечания, после устранения которых система будет принята в промышленную эксплуатацию. Все замечания, которые возникнут с момента составления настоящего списка и которые будут являться ошибками, будут устранены по гарантии. Остальные замечания будут устраняться силами отдела ИТ или силами подрядчика по договору сопровождения».

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

Заключение

В своей книге я постарался рассказать на своем опыте, «как небольшой фирме-партнеру 1С перестать выживать и начать зарабатывать». Компания, которую построили мы с партнерами, нашла свою нишу на рынке отраслевых решений под маркой «1С-Совместно» для ресурсоснабжающих предприятий – электрических сетей, теплосетей и водоканалов. Конечно же, разработка и продвижение отраслевого продукта – не единственный путь для успешного франчайзи. Чем бы вы ни занимались, крупными проектами или сопровождением небольших предприятий в сфере малого бизнеса, важно любить своих клиентов и помогать им работать эффективнее.

Если же вы решите пойти по пути разработки собственного отраслевого решения, я советую придерживаться следующих правил.

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

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

● Изучите похожие решения ваших конкурентов, так называемые «продукты-аналоги» и «продукты-заменители». Прежде чем начинать продвижение своего решения, выясните, чем оно лучше продукции конкурентов. Конечно же, определитесь с ценой, и помните, что демпинг – не самый лучший путь к успеху.

● Подготовьте базу данных ваших будущих покупателей. Узнайте все, что можете, о каждом, найдите среди них тех, кому ваш продукт нужен уже завтра. Разработайте не только сайт и буклет о продукте, но и продукты-трипваеры с небольшой ценой. Они помогут продавать тем клиентам, кто не готов платить сразу и много.

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

Список литературы

1. Дал У., Дейкстра Э., Хоор К. Структурное программирование = Structured Programming. 1-е изд. – М.: Мир, 1975. – 247 с.

2. Кент Уильям (февраль 1983 г.). «Простое руководство по пяти нормальным формам в теории реляционных баз данных». Коммуникации ACM. 26 (2): 120–125. DOI: 10.1145/358024.358054.

4. Паркинсон С. Н. Законы Паркинсона: Сборник/Пер. с англ.; сост. и авт. предисл. В. С. Муравьёва. – М.: Прогресс, 1989. – 448 с.

5. Маклаков С. BPwin и Erwin. CASE-средства для разработки информационных систем. – М.: Диалог-МИФИ, 2000. – 200 с.

6. Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению. 3-е изд., дополненное / Пер. с англ. – М.: Издательство «Русская редакция»; СПб.: БХВ-Петербург, 2014. – 736 стр.: ил.

7. Наполеон Хилл. Думай и богатей. Серия «Настольная книга бизнесмена». – М.: ФАИР, 1996. – 272 с.

8. Типовые нормы времени на программирование задач для ЭВМ. – М.: Экономика, 1989. – 126 с.

9. Траут Д., Ривкин С. Дифференцируйся или умирай. – М.: Питер, 2006. – 240 с.

10. Блох Артур. Закон Мерфи. Лоуренс Дж. Питер. Принцип Питера или Почему дела всегда идут вкривь и вкось / А. Блох, Л. Дж. Питер. – М.: Попурри, 2016. – 352 c.

11. Ильин Е. П. Работа и личность. Трудоголизм, перфекционизм, лень: [научное издание] / Е. П. Ильин. – Санкт-Петербург [и др.]: Питер, 2011. – 224 с.: ил. – (Мастера психологии). – Библиогр.: с. 181–195.

12. Фишер Р., Юри У., Паттон Б. Переговоры без поражения. Гарвардский метод. – М.: Манн, Иванов и Фербер, 2012. – 272 c.

13. Адизес И. К. Управление жизненным циклом корпорации. – М.: Питер, 2007. – 416 с.

14. Имаи М. Кайдзен. Ключ к успеху японских компаний / М. Имаи. – М.: Альпина Паблишер, 2016. – 305 c.

15. Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. – Издательство «Лори», 2001. – 256 с.