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