Сопровождение системы - этап, который должен следовать за завершением работ по построению системы.
Должен следовать - не значит обязательно последует. Если во время построения системы вам не удалось сохранить хорошие отношения с заказчиком, сопрождать систему вас не попросят. И это можно рассматривать как фиаско вас как инсталлятора.
Чтобы по возможности избежать этого неприятного момента, кроме выполнения договоренностей по срокам реализации, функционалу, аккуратному информированию заказчика о состоянии проекта и его развитии, и конечно, последующему обучению, договор на сопровождение системы стоит предложить заказчику еще на этапе построения этой системы.
[order][/order]Если некоторый объем некритичных работ по той или иной причине не был выполен на этапе построения системы, он может быть перенесен на этап сопровождения.
В договоре на сопровождение системы, кроме самого сопровождения, может быть прописан перечень работ по модификации и совершенствованию системы. Не редко бывает, что к концу строительства бюджет по другим видам работ (строительным, отделочным) оказывается существенно выше изначально запланированного. И на этап автоматизации денег остается заменто меньше, чем планировалось изначально. Понятно, что можно совсем отказаться от некоторых элементов и подсистем автоматики, но более разумным будет оговорить перенос построения таких, не критичных систем, на следующем этапе - этапе сопровождения.
В договоре на сопровождение указывается перечень плановых работ, которые необходимы для нормального функционирования системы, расписание их проведения, предположительная трудоемкость и стоимость этих работ.
Разумно предположить, что на первом этапе после сдачи объекта, объем работ по сопровождению будет максимальным. Обязательно будут выявлены какие-то моменты, которые желательно исправить. Логика работы отдельных элементов потребует доработки. Или заказчик захочет добавить дополнительные сценарии. Так бывает при работе любой сложной системы. Идет ее "притирка" к нуждам заказчика. И тут особенно важным становится готовность как заказчика, так и исполнителя к этому "всплеску" работ первого этапа. Если заказчик заранее будет об этом знать, проблемы организации подобных работ будут минимальны.
На этом этапе очень важным будет и то, на сколько построенная система отличается "гибкостью". Влечет ли небольшое изменение в одной ее части значительные переделки в других частях. Модульность построения системы, в том смысле, что внутренняя логика работы одного модуля оказывает минимальное влияние на другие модули, могут сильно помочь в этот момет.
Частым элементом работ на первом этапе сопровождения бывает проверка стабильности системы под "рабочей" нагрузкой. Люди начинают жить в здании, пользоваться медиа сервисами, проводным и беспроводным интернет доступом, и т.д. Если система построена с запасом, такой рост нагрузки не вызовет заметного влияния на скорость работы отдельных компонентов, на отзывчивость системы в целом. Но бывает, что возникает нагрузка, которую никто, в том числе и заказчик, не мог предположить. В таком случае скорость диагностики системы и подбор правильного решения из уже наработанного инсталлятором "аварийного комплекта" выступает на первый план.
Правильно спроектированная и реализованная система должна позволять быстро выполнять диагностику ее отдельных частей. Скажем, если вдруг доступ в Интернет резко замедлился, у вызванного для решения этой задачи инженера уже должен быть с собой check list, проведя проверку по которому, сотрудник компании инсталлятора сможет "поставить диагноз" системе и предложить один из вариантов его решения. Варианты тоже желательно продумывать заранее. Породить осмысленный вариант "из головы" в стрессовых условиях типа: "у нас ничего не работает, срочно исправьте!" бывает очень не просто.
Но если заранее подготовиться к такой ситуации, разрешить ее удается за минимальный срок и минимальными средствами.