28. Договор на внедрение.

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

РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ и отв. представителями заказчика вырабатывается и подписывается ДОГОВОР НА ВНЕДРЕНИЕ (по результатам подписанных ТЗ и плана графика работ). В нем оговариваются условия и сроки выполнения этапа II внедрения, который включает: разработку конфигурации, тестирование конфигурации, обучение администраторов и персонала, подготовку пользовательской документации, сдачу-приемку конфигурации, опытную эксплуатацию.

Продолжительность выполнения этапа II внедрения составляет обычно не менее одного месяца.

Рекомендации по форме составляемого договора см. [1, раздел 7.6].

29. Есть ли потребность в дополнительных исполнителях?

Комплексное внедрение, как правило, предполагает участие группы экспертов. Ведущая роль, как уже говорилось, принадлежит ПОСТАНОВЩИКУ проекта. Кроме него, в разработке может принимать участие один или несколько специалистов-кодировщиков, главная задача которых состоит в написании тех документов и отчетов, которые требуются постановщику. На завершающем этапе потребуется специалист по обучению персонала заказчика.

К этой работе полезно привлечь эксперта (не кодировщика) имеющего больше опыта в общении с людьми, нежели с программированием.

30. Определение и подключение дополнительных исполнителей.

Проекты по внедрению, в которых принимают участие несколько исполнителей, гораздо более сложны в управлении, однако именно в таких проектах эффективность работы фирмы наиболее высока. В тех случаях, когда мы имеем большой объем работ, причем зачастую в смежных областях (например, стыковка с торговым оборудованием и сложный бухгалтерский учет), либо проект имеет жесткое ограничение по срокам, оправдано привлечение к работе нескольких специалистов. При этом возможно назначение РУКОВОДИТЕЛЯ ПРОЕКТА (особенно это характерно для крупных и многогранных задач), которому передаются все необходимые полномочия и на которого возлагается вся полнота ответственности за его выполнение. В разных случаях функции руководителя проекта могут осуществлять ПОСТАНОВЩИК или руководитель группы по работе над комплексными заказами.

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

31. Разработка конфигурации.

На основе ТЗ разрабатывается конфигурация, учитывающая конкретные потребности заказчика.

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

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

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

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

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

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

32. Тестирование.

Целесообразно предварительное тестирование вновь разработанной конфигурации проводить на специально собранном для этой цели полигоне на территории Исполнителя с обязательным присутствием представителей Заказчика.

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

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

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

При проверке документов, необходимо заводить данные близкие к реальным, т.е. осуществлять проверку по «живым» документам. Это позволяет избежать мелких, но досадных ошибок (например: не хватает разрядности у числовых переменных, не «влезает» наименование и т.п.). Если справочник имеет несколько уровней, то нужно сразу создать группы во избежание ошибок, связанных принадлежностью элементов к группам. Если с документом, предполагается работа нескольких пользователей с разными правами, то необходимо сразу создать соответствующие наборы прав, особенно если разделение доступа производится средствами языка.

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

33. Обучение администраторов.

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

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

34. Обучение персонала.

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

См также рекомендации по обучению[2, раздел «Типовой набор услуг»].

35. Подготовка пользовательской документации.

Обучение пользователей не освобождает внедренцев от подготовки пользовательской документации. Эта задача начинается с описаний к справочникам и документам, которые делаются еще на этапе создания макетной конфигурации (т.е. при выполнении задачи 31). В процессе написания алгоритмов для проведения документов, эти описания пополняются, затем редактируются и собираются в один файл (документ). Файл желательно снабдить для наглядности иллюстрациями.

36. Сдача-приемка конфигурации.

Сдача-приемка конфигурации осуществляется на территории Заказчика в присутствии его представителей и представителей Исполнителя. Конфигурация проверяется на соответствие всем пунктам ТЗ. По факту сдачи-приемки составляется и подписывается соответствующий акт.

37. Опытная эксплуатация.

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

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

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

38. Проработка условий выполнения этапа III внедрения.

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

39. Закрытие этапа II внедрения.

По аналогии с задачами 10 и 16.

40. Заказчик идет на дальнейшее сотрудничество?

По аналогии с задачей 11.

страница 3

страница 4