Регламент взаимодействия Сторон

Приложение

к Договору об оказании услуг

по внедрению программного обеспечения

№ __ от «___» 200_ г.

Регламент взаимодействия Сторон

Настоящий Регламент является неотъемлемой частью Договора об оказании услуг по внедрению программного обеспечения № __ от «___» ___________200_ г. (далее – Договор).

Регламент предусматривает порядок взаимодействия Сторон по исполнению Договора в части технической реализации обязательств по Договору.

Регламент обязателен для ознакомления сотрудникам (представителями) Сторон, напрямую исполняющих настоящий Договор, сотрудникам Заказчика, использующих при выполнении своих обязанностей программу «Бизнес-планирование».

Регламент в редакции, существующей на момент подписания Договора, подписывается в 2-х экземплярах. Последующие редакции Регламента Сторонами не подписываются, а утверждаются в порядке, предусмотренном п.3.1.3 Договора.

Регламент составлен на 7 (семи) листах.

Глоссарий

Внутрифирменные Регламенты и Положения – текстовые документы, имеющие силу внутреннего закона предприятия, которое является фактическим Заказчиком услуг (хотя договор заключается с одной из организаций этого предприятия).

Журнал работы в офисе Заказчика – набор бумажных листов, где фиксируется каждая работа сотрудников Исполнителя в офисе Заказчика, с указанием номера листа, номера записи, даты, времени, результатов работы, причем каждая такая строка содержит подписи сотрудников Заказчика и Исполнителя.

Настройка кодирования – операция, которая обязательно должна выполняться при внедрении программы «Бизнес-планирование» в части управленческого учета, заключается в заполнении электронной таблицы, где в каждой строке содержится, с одной стороны, набор значений реквизитов первичного документа или проводки, а с другой стороны, содержатся значения управленческой аналитики, которые надо проставить в документ. Например, одна строка этой таблицы может содержать такую информацию: документ – Приходный кассовый ордер; условие: Счет бухгалтерского учета - 71; значение: Статья оборотов – Поступление денег при возврате с подотчета. В процессе настройки кодирования такого рода записи добавляются в таблицу.

Организации, подлежащие управленческому учету – организации, входящие в предприятие, которое является фактическим Заказчиком услуг (хотя договор заключается с одной из организаций этого предприятия).

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

Предприятие – объект управленческого учета и планирования, фактический Заказчик проекта, хотя договор заключается с одной из организаций, входящей в предприятие.

Программа «Бизнес-планирование» - конфигурация на платформе «1С:Предприятие 8», собственная разработка Исполнителя, предназначена для автоматизации всех функций финансового подразделения предприятия, кроме бухгалтерского учета.

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

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

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

Типовые конфигурации системы «1С:Предприятие» - конфигурации на платформе «1С:Предприятия 8», поставляемые третьими разработчиками, в том числе поставляемые той же компанией, которая создала эту платформу (1С»).

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

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

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

1. Составление, согласование и изменение Технических заданий

1.1. Техническое задание (далее Задание) на услуги по внедрению программы «Бизнес-планирование» (далее Программы) составляется Исполнителем на основе изложенных в устной или письменной форме требований Заказчика. Техническое задание составляется в течение 5 (пяти) рабочих дней с момента изложения или передачи очередных требований Заказчика.

1.2. На готовый функционал Программы, описанный в Руководстве пользователя (далее – Руководство), Задание не составляется. В случае вопросов по соответствию готового функционала Руководству критерием является то Руководство, которое передано Заказчику при установке программы на установочном компакт-диске.

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

1.4. Допускается при заключении договора подписать предварительное Задание, в котором стоимость услуг названа в виде интервала от и до, а перечень услуг – в виде утверждений «Если выясняется, что … то тогда … ». В этом случае Исполнитель обязан уточнить Задание при первой возможности, не увеличивая стоимость выше максимального согласованного предела.

1.5. В ходе выполнения Задания Исполнитель может выяснить, что: 1) для выполнения Задания Заказчик должен ввести дополнительную информацию; 2) нужна доработка учетной базы данных программистом, который не является Исполнителем по данному договору; 3) есть другие обстоятельства, в том числе связанные с аппаратной частью, которые не были известны при составлении Задания, из-за которых Задание невозможно выполнить в срок, либо некоторые его пункты в описанном виде невозможно выполнить. В этом случае Исполнитель должен известить Руководителя проекта со стороны Заказчика (далее – Руководителя проекта) о создавшейся ситуации. Задание должно быть скорректировано Исполнителем согласно выясненным обстоятельствам в срок 3 (три) рабочих дня с момента выяснения этих обстоятельств и подписано заново.

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

1.7. В случае разногласий по изменению Задания Руководитель проекта обязан организовать совещание с участием руководителей предприятий – Сторон. На время устранения разногласий работы по Заданию приостанавливаются и сроки работ увеличиваются на время согласования Задания.

1.8. Техническое задание должно соответствовать требования п.2.1, 9.2 Договора.

2. Составление внутрифирменных документов Заказчика (Приказов, Регламентов, Положений, должностных инструкций)

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

2.2. Если в Задании явно не говорится о создании внутрифирменных документов, то делаются только следующие документы: 1) при внедрении системы управления платежами – Приказ о порядке согласования платежей; 2) при внедрении системы управленческого учета – Приказ о порядке составления управленческой отчетности; 3) при внедрении системы бюджетирования «снизу» - Приказ о порядке составления бюджетов; 4) изменения в должностных инструкциях тех сотрудников, которые будут работать в Программе.

2.3. Согласование Регламентов и Положений проводится в электронном или бумажном виде. Первая версия составляется Исполнителем и передается, как правило, на бумаге всем сотрудникам по списку. Если согласующий сотрудник считает нужным высказать замечания лично (т. е. не исправлять текст самому, а в свободной форме выразить свое мнение устно), то он сообщает об этом как можно скорее Исполнителю или Руководителю проекта для назначения встречи.

2.4. Внесение доработок по замечаниям делает Исполнитель в течение 2 (двух) дней с момента передачи ему доработок. В случае противоречивых замечаний разных сотрудников составляется список разногласий. Руководитель проекта обязан организовать совещание или заочное согласование спорных мест в тексте Положений и Регламентов в срок не менее 2 (двух) дней с момента передачи ему списка разногласий.

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

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

3. Протокол тестирования

3.1. Протокол тестирования (далее Протокол) нужен в том случае, когда Руководитель проекта не может в силу своей компетенции проверить работу функционала, и тестированием занимается другой сотрудник Заказчика. Тогда внутренним документом для руководителя проекта, который подтверждает выполнение работ, может быть протокол тестирования. Протокол не идентичен акту выполненных работ и имеет смысл внутрифирменного документа.

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

3.3. В случае, если используется Протокол, он должен быть распечатан на бумаге. Протокол содержит перечень действий пользователя, который надо проверить в работе программы. В Протоколе должно быть место для того, чтобы пользователь мог вписать замечания вручную, а также должен быть указан крайний срок тестирования. Бланк Протокола печатается в двух экземплярах, один передается сотруднику Заказчика, которому поручено тестирование, а на другом этот сотрудник должен сделать надпись: «Протокол тестирования получил» и расписаться. Второй экземпляр хранится в документации проекта у Исполнителя. После тестирования сотрудник Заказчика возвращает заполненный Протокол сотруднику Исполнителя, который обязан сделать копию с документа, заполненного вручную, и сохранить оригинал в документации по проекту, которая хранится у Исполнителя. Копия, при наличии замечаний, передается разработчику программы – сотруднику Исполнителя, после устранения замечаний процедура передачи повторяется. При отсутствии замечаний копия подписанного Протокола передается Руководителю проекта.

4. Журнал работы в офисе Заказчика и Журнал передачи рабочей информации

4.1. Все без исключений работы сотрудников Исполнителя в офисе Заказчика должны отражаться в Журнале работы в офисе Заказчика (далее Журнал работы), который ведется на бумаге в одном экземпляре. В Журнал вносится дата, время от и до, причина посещения или обсуждаемые вопросы, и в каждой строке делаются подписи с расшифровкой сотрудников Заказчика и Исполнителя.

4.2. Все без исключения передачи информации на любом материальном носителе (бумага, CD или DVD-диск, флэш-накопитель) между Исполнителем и Заказчиком должны отражаться в Журнале передачи рабочей информации (далее Журнал информации), который ведется на бумаге в одном экземпляре. В Журнал вносится дата, время, какая информация передавалась, носитель, от кого к кому передавалась информация, и в каждой строке делаются подписи с расшифровкой сотрудников Заказчика и Исполнителя.

4.3. Сотрудники Заказчика обязаны подписывать Журналы, проверив правильность сделанной записи, по первому требованию сотрудника Исполнителя. Если в работе участвовали несколько сотрудников, то подписать каждый Журнал должен в порядке приоритета: либо Руководитель проекта, либо старший по должности, либо тот сотрудник, вопросы которого обсуждались большую часть времени.

4.4. Журналы хранятся у Исполнителя в документации проекта. Копии Журналов предоставляется Заказчику по первому требованию.

5. План внедрения

5.1. План внедрения – это документ проекта, в котором в виде таблицы расписаны действия Заказчика и Исполнителя с указанием сроков и результатов.

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

5.3. Если План внедрения используется, его должен подготовить Исполнитель. План внедрения распечатывается в двух экземплярах, его должны подписать Руководитель проекта и Исполнитель.

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

6. Порядок взаимодействия Сторон при составлении классификатора оборотов и аналитических справочников

6.1. В Задании должно быть явно указано, кто и какую информацию предоставляет для заполнения справочников. Если не указано иное, классификатор и аналитические справочники создаются Исполнителем сразу в программе «Бизнес-планирование» (далее Программа), а для согласования используются распечатки из Программы.

6.2. Для разработки классификатора используется существующая на предприятии управленческая отчетность, справочники учетной базы данных. Если в Задании не сказано иное, то Заказчик предоставляет Исполнителю копию учетной базы данных и, если есть, управленческие отчеты в Excel.

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

6.4. Руководитель проекта должен организовать эти встречи, либо самостоятельно подготовить информацию. Если к согласованию справочников подключаются другие сотрудники Заказчика, Руководитель проекта должен предоставить исполнителю список сотрудников, чье мнение должно быть учтено при составлении справочников.

6.4. Первая версия справочников вводится в Программу Исполнителем, затем средствами программы выгружается в Excel и передается Руководителю проекта в электронном виде. Затем также в электронном виде обратно передаются замечания Заказчика. По согласованию справочников могут быть назначены встречи в офисе Заказчика. Для встречи Исполнитель должен подготовить распечатки справочников на бумаге по количеству участников встречи.

6.5. Справочники редактируются и согласовываются необходимое количество раз, пока они не будут устраивать всех сотрудников по списку. Далее Исполнитель обязан распечатать справочники со списком сотрудников Заказчика и подписать получившийся документ. Если в состав технического задания включена настройка двойной записи по статьям классификатора оборотов, то в распечатке должно быть указание счетов дебета и кредита по каждой статье оборотов. Такая распечатка делается в одном экземпляре и хранится у Исполнителя. По требованию Заказчика может быть сделан второй экземпляр или копия этого документа.

6.6. Если Стороны договорились, что справочники составляет Заказчик, а Исполнитель только вводит их в программу, то передаваемые справочники, кроме предоставления в электронном виде, должны быть распечатаны и подписаны Руководителем проекта. После ввода справочников в программу Исполнитель делает распечатку данных, введенных в Программу, и передает ее руководителю проекта, который должен организовать проверку распечатки и подписать ее. Такая распечатка делается в одном экземпляре и хранится у Исполнителя. По требованию Заказчика может быть сделан второй экземпляр или копия этого документа.

6.7. Работы по внедрению функционала Программы не могут быть начаты без ввода в нее утвержденных управленческих справочников. Но Стороны могут договориться, и это должно быть явно написано в Задании, что работы по внедрению учета и планирования начинаются на типовом классификаторе оборотов без его предварительного согласования. В этом случае в стоимость внедрения будет заложена дополнительная сумма за переделывание работы при изменениях классификатора оборотов и аналитических справочников.

7. Порядок взаимодействия Сторон в процессе осуществления настройки кодирования и получения управленческих отчетов

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

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

7.3. Руководитель проекта должен составить список всех сотрудников, кто компетентен в проверке настройки кодирования и управленческих отчетов за тестовый месяц по организациям холдинга, которые войдут, согласно Заданию, в систему управленческого учета. Список должен быть таблицей с фамилией сотрудника, его телефоном, и названием организации, по которой он должен проверить управленческие отчеты, и срок проверки. Сотрудники, перечисленные в списке, должны быть предупреждены Руководителем проекта о дополнительном объеме работ и сроках их выполнения.

7.4. Должны быть назначены сотрудники Заказчика, которых надо научить процедуре кодирования и которые в дальнейшем будут составлять управленческие отчеты в Программе. Оптимально, если эти сотрудники будут теми же, кому поручена проверка управленческих отчетов.

7.5. Решения, принятые по настройке кодирования, а также список сотрудников, проверяющих управленческие отчеты, должны быть внесены в Задание либо Приложение к нему и подписаны обеими Сторонами.

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

7.7. Исполнитель обязан использовать для настройки кодирования наиболее общие условия, те, что не меняются от месяца к месяцу. Например, нежелательно привязывать кодировку к конкретным контрагентам и конкретной номенклатуре, т. к. сегодня канцтовары купили у , а завтра купят у ИП Сидоров, и кодировка уже не сработает. Аналогично, сегодня купили Кирпич марки А, а завтра Кирпич марки Б, но для управленческого учета это одна и та же статья оборотов. Поэтому общее правило: 1) делать минимум условий в каждой настройке кодирования, условия должны быть те и только те, которые действительно нужны; 2) привязывать к условиям в первую очередь бухгалтерский план счетов и справочники бухгалтерских статей (например, Статьи движения денежных средств); 3) если все-таки приходится использовать объемные первичные справочники номенклатуры, контрагентов, физических лиц, то надо использовать не конкретные элементы справочников, а группы максимально высокого уровня, чтобы на следующий месяц та же кодировка сработала для другого элемента той же группы.

7.8. После выполнения этой работы Заказчик должен проверить в базе данных Программы: 1) сами настройки кодирования, пользуясь распечаткой соответствующего справочника; 2) все методики управленческого учета (как правило, для каждой организации, подлежащей управленческому учету, получается отдельная методика управленческого учета); 3) получившиеся управленческие отчеты за тестовый месяц по всем заявленным в Задании аналитикам. Если не указано иное, результаты проверки предоставляются Исполнителю в виде файлов Excel, получившихся сохранением отчетов и настроек кодирования из Программы в формате *.xls, где написаны замечания в соответствующих ячейках.

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

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

7.11. Если в Задании указано, что в управленческих отчетах должны быть вычисляемые строки, Заказчик должен предоставить пример расчета, можно в формате *.xls или в виде текстового описания. Проверку вычисления формул должны провести сотрудники Заказчика, порядок предоставления замечаний тот же.

7.12. Исполнитель обязан в процессе или по окончании процедуры согласования управленческих отчетов убедиться, что сотрудники, которым поручено вести составление управленческой отчетности в дальнейшем, знают, как получить эти отчеты за очередной месяц. Для этого проводится обучение каждого сотрудника, о чем делается запись в Журнале работы в офисе Заказчика. В процессе обучения сотрудник должен выполнить всю процедуру самостоятельно, от загрузки внешних данных до получения управленческого отчета. Обязательно сотрудник должен освоить навык настройки кодирования, т. к. созданная кодировка ежемесячно дополняется на 5-20%, в зависимости от разнообразия первичных документов.

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

8. Порядок внедрения готового функционала Программы

8.1. Внедрение готового функционала Программы, описанного в Руководстве, может не быть явно включено в Задание. В этом случае внедрение выполняется Заказчиком самостоятельно. Исполнитель выполняет свои обязательства по гарантийному обслуживанию, перечисленные в Договоре. Допускаются без увеличения стоимости работ консультации в офисе Заказчика, если сотрудник Исполнителя присутствует в офисе Заказчика по другим вопросам проекта. В этом случае вопрос должен быть занесен в Журнал работы в офисе Заказчика.

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

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

8.4. Обучение документируется записями в Журнале, обязательно с подписью обучаемых сотрудников. Если обучение проводится в офисе Исполнителя или в третьем месте, запись в Журнале делается как обычно.

9. Порядок разработки и внедрения функционала, написанного по требованиям Заказчика

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

9.2. Инициатор Задания со стороны Заказчика, если это не Руководитель проекта, должен быть указан явно в Задании в виде: фамилия, должность, телефон.

9.3. Необходимость составления Протоколов тестирования должна быть явно прописана в Задании, иначе они не составляются.

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

9.5. Выполнение Задания происходит независимо от остальной работы по проекту, если только его результаты не нужны для выполнения других Заданий по проекту.

10. Порядок передачи от Заказчика Исполнителю и устранения замечаний по работе программы, в том числе при обращениях по горячей линии

10.1. Вопросы и замечания по работе программы и обнаруженные ошибки передаются Исполнителю любым удобным способом: при встрече, по телефону, по электронной почте. Поскольку Заказчик при передаче вопроса не знает, ошибка ли это в программе, или не было выполнено какое-то условие ввода данных, то он передает все возникающие вопросы. Исполнитель обязан в срок, если в Договоре не указано иное, 2 (два) рабочих дня отреагировать на вопрос.

10.2. Реакция на вопрос может быть в одном из следующих вариантов: 1) рекомендация по вводу данных, по заполнению констант и настроек; 2) признание ошибки в программе и сообщение, когда она будет устранена; 3) запрос на дополнительную информацию или предложение о встрече в офисе Заказчика с целью уточнения вопроса.

10.3. Дополнительной информацией к вопросу Заказчика может быть: 1) просьба прислать скриншот при появлении ошибки или текст сообщения об ошибке, выходящий по кнопке «Подробно» при системном сообщении об ошибке; 2) просьба выгрузить поставляемой в составе Программы обработкой определенную информацию и прислать ее по электронной почте; 3) в исключительных случаях нужна копия базы данных Заказчика либо визит в офис Заказчика и работа по отладке программы на месте. Срок реакции на вопрос увеличивается на время предоставления дополнительной информации.

10.4. Устранение ошибок обычно передается Заказчику в виде обновления программы, высланного по электронной почте.

10.5. Исполнитель не имеет возможности устранить ошибки платформы «1С:Предприятие», т. к. разработчик платформы - 1С», и код платформы закрыт (может помочь смена релиза платформы на более новый). В случае выявления ошибок платформы, либо ошибок, связанных с доступом по локальной сети, либо аппаратных проблем, Заказчик обращается к специалистам в соответствующей области самостоятельно.

11. Порядок действий при выявлении необходимости доработок учетных баз данных Заказчика

11.1. Если в результате работ по кодировке принято решение об изменении данных учетных баз (например, выясняется, что нужное разделение информации не удается получить ни по какому признаку первичных документов), то выполнение Задания приостанавливается на время внесения дополнительных данных за тестовых месяц.

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

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

11.4. Решение по необходимости ввода дополнительных данных и доработок принимает Руководитель проекта.

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

12. Порядок действий в случае, если в Задание включено внедрение или доработка одной или нескольких типовых конфигураций системы «1С:Предприятие»

12.1. Внедрение типовых конфигураций системы «1С:Предприятие» выполняется по тем же правилам, что и внедрение Программы, т. е. составляются Задания, и работа передается в виде обновлений конфигурации.

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

12.3. Работа горячей линии Исполнителя не распространяется на другие конфигурации, кроме программы «Бизнес-планирование».

13. Порядок действий при смене Руководителя проекта со стороны Заказчика

13.1. Если Заказчик принимает решение о смене Руководителя проекта, то он обязан в течение 2-х рабочих дней сообщить об этом Исполнителю, с указанием нового Руководителя проекта либо исполняющего его обязанности сотрудника (нужно сообщить фамилию, должность, телефон). При отсутствии указаний о том, кто будет руководителем проекта, Исполнитель обращается непосредственно к Директору Заказчика.

13.2. Смена Руководителя проекта оформляется приложением к Договору.

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

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

13.5. Если Руководитель проекта заменен временно (в связи с болезнью или отпуском), то на время его замены все решения замещающего лица, существенные для объема работ по проекту, должны быть документированы Протоколом рабочего совещания, подписанного замещающим лицом.

ИСПОЛНИТЕЛЬ:	ЗАКАЗЧИК:
Директор бизнес-планирования» __________________ / /	Директор _____________________» __________________ / ______________________ /