зачем нужна техническая поддержка программного обеспечения
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки IT продуктов»
С чего все начинается
что есть служба поддержки и для чего она нужна?
Хотя вопрос звучит просто, но ответ на него дать не так то и просто. И причиной этому является далеко не сложность этой сферы деятельность. Причина в том, что тут присутствует маленькая особенность — «служба поддержки», равно как и «поддержка» вообще, не являются универсальными понятиями. Их значения очень сильно зависят от конкретной ситуации, которую мы рассматриваем. И чтобы это показать, я приведу один, очень схематичный пример.
Допустим, у нас есть компания — производитель автобусов, в которой наличествуют отделы «разработки и производства» и отдел «технического обслуживания», который осуществляет гарантийное обслуживание проданных автобусов. Есть также вторая компания — потребитель, которая купила один из автобусов, чтобы возить своих сотрудников по некому маршруту внутри кампуса/офисного городка. Так вот, в данном конкретном примере мы получаем следующую картину:
Но это хорошо видно на примере с автобусами, но, почему-то, совсем не очевидно в случае IT.
Давайте попробуем разобраться несколько подробнее.
Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает. Получается некий парадокс, вроде бы и там и тут – IT сфера, и там и тут вполне себе грамотные сотрудники и руководители, но в одном случае все в принципе работает вполне себе даже приемлемо, а в другом – как получится. В чем же разница? Почему мы можем обеспечить поддержку оборудования, ОС, вебсервисов, но при этом с поддержкой бизнес-платформ, таких как учетные системы, системы анализа данных, документооборота, управления бизнес-процессов и прочих – зачастую возникают сложности? В чем может быть загвоздка?
Возьмем другой пример, чуть более приближенный к нашей тематике. Итак, у нас есть компания, которая использует некую «стандартную» конфигурацию учетной системы (неважно какой). Поскольку конфигурация стандартная, то компания не имеет в штате разработчиков для внесения исправлений и изменений в используемую систему. Вполне очевидно, что у пользователей возникают разного рода проблемы и вопросы с применением данной системы. Пользователи, это люди несколько далекие от IT («продажники», бухгалтера, начальники и т.д.) и вникать в детали, как оно собственно работает внутри, им нелегко, да и просто некогда.
На этом моменте давайте остановимся чуть подробнее. Итак, у нас это чистая компания – потребитель. То есть сама компания не производит продукт, которым пользуется, а покупает его на стороне. В этом случае, если нет своей «службы поддержки», то конечные пользователи сами пытаются решать возникающие проблемы. В результате теряется много времени, нервов, начинаются чудеса с данными и т.д. В общем, все как всегда.
И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.
Едем дальше, а как же оценивать работу сотрудников этой службы? Скоростью решения проблемы? Скорее нет, чем да, поскольку они не могут, да и не должны лезть вовнутрь конфигурации или платформы учетной системы. Поэтому немного утрируем, и получается, что их задачи тоже вполне очевидны — удостовериться, что:
Итак, на текущий момент мы, в общем, двигаемся в верном направлении. Примерно об этом нам говорят книжки из ITIL, множество прочитанных статей, да и логика тоже это подтверждает. И на самом деле, тут откровений нет. Но они будут дальше.
Итак, у нашего руководителя все получилось хорошо, все счастливы, и уже компания – производитель этой самой учетной системы, пригласила его/ее наладить их «службу поддержки». И вот тут начинаются чудеса. На новом месте он/она вновь задается теми же самыми вопросами, что и ранее:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
И вот в этом случае, ответы уже будут очень сильно отличаться от того, что мы видели ранее. Итак, мы имеем дело с компанией – производителем. То есть компания имеет штат разработчиков, которые придумывают и воплощают в жизнь свои идеи в некоем продукте, которым пользуются другие компании. И получается, что при отсутствии «службы поддержки», именно разработчики вынуждены отвлекаться от своей основной работы и заниматься пустяковыми (по их мнению) проблемами, в то время, когда «вселенная нуждается в идеальной учетной системе». 
Иными словами, в данном случае, заказчиком услуг «службы поддержки» являются уже не пользователи, а разработчики. И им уже не нужно требовать, чтобы сотрудник отдела что-то там собирал и отдавал им, тут уже необходимо, чтобы эта служба была в состоянии сама решать большинство проблем. Понимаете разницу?
Получается, что при похожем названии, и вроде бы, как одной функции, у отделов совершенно разные требования к их работе. То есть мы имеем два полюса, два чистых и совершенно противоположных подхода к организации работы «службы поддержки». К большему сожалению, эту разницу мало кто видит, а из тех, кто видит, ее часто игнорируют.
Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.
Резюмируя, мы получаем следующую картину:
Очевидно, что в реальной жизни нам приходится использовать некий компромисс и смешение этих двух противоположностей, но, тем не менее, зная эти «ингредиенты» руководитель уже сможет подготовить свой собственный рецепт, наиболее полно соответствующий условиям конкретной организации, выстроить соответствующие процессы и подготовить SLA, которые будет отвечать интересам всех заинтересованных сторон (включая отдел поддержки/сопровождения).
К чему обычно приходим
Ну и в качестве бонуса, небольшой список неудачных подходов к организации работы службы поддержки.
С другой же стороны, когда к Вам обращается некий «Федор», это далеко не всегда комфортно, поскольку Вы не знаете этого человека, его никто не представлял, чтобы разводить «панибратство» и вообще, как Вы можете быть уверены, что «Федор» это его реальное имя?
Поэтому всегда, при любом ответе компании в подписи должны быть, как минимум, фамилия и имя человека, отправившего сообщение. Даже если данное письмо/сообщение идет от коллектива в целом. Кроме того, если обращение начал обрабатывать один сотрудник, то он и ведет работу по данному конкретному инциденту до конца, без постоянного переключения участников со стороны компании. Смена допускается лишь при необходимости (например, заболел, или перегружен более важными запросами, или же работу «подхватили» сотрудники «технической поддержки») и новый ответственный сотрудник всегда должен представиться и указать будет ли он до конца работать по заявке, или же только временно ее обрабатывает. Вообще, все это очень странно и создается впечатление, что основами административной работы многие менеджеры просто не владеют.
Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.
Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.
Кроме этого, анализ работы служб поддержки позволяют оценить и качество работ внешних поставщиков услуг и/или отдела разработки. Эту часть анализа деятельности зачастую вообще игнорируют.
На этом у меня все. Ваши комментарии и аргументированные замечания – всячески приветствуются.
Всем удачи и успехов.
1. «Мерзлый» песик — отсюда
2. «Суровый» пес отсюда
3. Call-центр: отсюда
4. Автобусный сервис отсюда
Поддержка программного обеспечения
Мы завершаем нашу трилогию о принципах разработки, принятых в «Эдисоне», постом о том, как устроена поддержка разработанного ПО, включая внедрение (установку и обучение использованию) и сопровождение (правку выявленных багов и поддержку пользователей).
Надёжная поддержка — это важно
Объекты техподдержки
Профиль нашей деятельности включает как разработку собственных проектов для широкого пользователя, так и разработку софта на заказ.
Кроме техподдержки по произведенным нами продуктам (как тиражируемым, так и сделанным на заказ), мы осуществляем сопровождение сторонних решений, используемых нашими клиентами.
Тиражируемое ПО EDISON
На сегодня в нашем портфолио 4 продукта, доступных для всех желающих:
Заказное программное обеспечение
Системы автоматизации на базе сторонних продуктов
Внедрение и сопровождение решений автоматизации на платформах Oracle, SAP, 1С, Microsoft, а также SpiderProject, ProjectMate, bugzilla, mantiss, jira и других, например:
Специалисты нашей компании отлично разбираются во всем интегрируемом программном обеспечении, а инженеры-программисты, работающие с 1С, имеют глубокие знания в бухгалтерском, управленческом учете и расчете заработной платы.
Как устроена поддержка программного обеспечения в EDISON
В соответствии со статьей № 470 ГК РФ производитель должен давать гарантию на свои программные продукты, а именно: исправлять свои ошибки либо менять продукт на другую версию. Проблема в том, что по закону для этого требуется экспертиза, подтверждающая наличие сбоя, доказывающая вину разработчика, исключающая пользовательское вмешательство в код ПО, гарантирующая корректное использование продукта клиентом и т.д. На время проведения экспертизы неисправности программного комплекса парализуется не только его работа, но и работа аппаратного обеспечения. И это очень неудобно для пользователей сервисов, которые должны работать постоянно.
Услуга техподдержки, в соответствии с которой специалисты EDISON исправляют все недостатки, в том числе инициированные пользователем и не включенные в изначальное ТЗ, призвана компенсировать эти недочёты.
Независимо от того, требуется ли поддержка по корпоративному сайту или системе автоматизации на базе Oracle, порядок ее оказания одинаков (меняется лишь срок в зависимости от сложности задачи).
Техническая поддержка пользователей ПО может включать большое количество опций в зависимости от желаний клиента, например:
За каждым клиентом мы закрепляем проект-менеджера, с которым ведется вся коммуникация. Для контроля за ходом работы и затраченным на выполнение задач временем клиенту предоставляются неограниченные по времени доступы к репозиторию, системе управления проектами и программе учета времени ББ, о которой мы писали выше.
Сайты могут управляться клиентами самостоятельно, используемые нами CMS: Bitrix, WordPress, Joomla, Drupal, Amiro, Frog, Kentico, AxCMS, Sitefinity. Поддержка веб-сайта включает в себя, в том числе, своевременное информирование о необходимости оплаты хостинга и домена.
Преимущества в поддержке программного обеспечения
Доработка программного обеспечения
IT-рынок — структура быстро растущая и динамичная (меняются стандарты, требования, технологии), и бизнес наших клиентов тоже не стоит на месте (появляются новые задачи), поэтому помимо поддержки программного обеспечения EDISON осуществляет доработки ПО, а именно:
Реинжиниринг программного обеспечения
В случае если разработчик продукта более не поддерживает установленное у клиента программное обеспечение, переход на новое проблематичен, и поддержка существующей системы обходится слишком дорого, при наличии технической возможности производится реинжиниринг — то есть создание перепроектированной версии старого ПО с учетом новых требований. Миграция происходит постепенно, что позволяет избежать рисков.
Интернационализация и локализация программного обеспечения
Хотя оба этих понятия относятся к «язычности» продукта, интернационализация подразумевает адаптацию под любой язык (конфигурация изменяемых при смене языка параметров, таких как вывод чисел, дат, денежных знаков), тогда как локализация — перевод языка интерфейса, файлов программы и справки на конкретный язык.
Портирование и миграция
К этим доработкам относятся работы по переносу, конвертации форматов БД, межплатформенной миграции, переводе ПО с одного языка программирования на другой и адаптации.
Один из примеров, демонстрирующих портирование и миграцию:
При доработке программного обеспечения мы действуем по тем же принципам, что и при его создании, что гарантирует высокое качество работы в нужный срок.
Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях или на нашей странице в Фейсбуке.
Рекомендации от экспертов. Блог Okdesk
Сложные технические инструменты проникают в жизнь обычных людей и рядового бизнеса. Поддержка — плотно ассоциируется со службой производителя ПО и оборудования или исполнителей проекта (например, разработки и дальнейшего обслуживания сайта), которая помогает пользователям правильно настроить и эксплуатировать сложный продукт, а также быстро устранять возникающие неполадки.
Так ли это? Чем вообще занимается техподдержка? Как она связана с продажами компании? Кому нужно задуматься о ее организации и многое другое в нашей заметке.
Функции техподдержки
Техподдержка — это, фактически, инструмент постпродажного обслуживания, если оно предусмотрено. Пользователи контактируют с ее сотрудниками либо после покупки оборудования или сервиса, либо по завершении проекта — это может быть создание программного решения, сайта или даже внедрение целой инфраструктуры — к примеру, комплексной системы видеонаблюдения.
Задача поддержки — принимать обращения клиентов, у которых возникают проблемы, фиксировать их и решать (в момент обращения или после — в соответствии с Соглашением об уровне сервиса — SLA). Иногда для решения проблемы клиента достаточно ответа на вопрос, а в других случаях требуется передать заявку профильному специалисту, который разберется в проблеме, даст развернутое объяснение и вернет работоспособность решению.
Каким бы ни было обращение, от специалистов поддержки требуется восстанавливать работу обслуживаемой инфраструктуры, ПО или услуги в кратчайшие сроки, для чего используются механизмы управления инцидентами. Формальное определение понятия «как можно быстрее» обеспечивает упомянутое выше соглашение об уровне сервиса — SLA, которое поддержка старается соблюдать или даже превосходить.
Помимо общения с клиентами, поддержка реализует важную функцию получения обратной связи от пользователей (обычно этим занимаются диспетчеры или «первая линия поддержки»), т.е. обеспечивает информацией отдел развития бизнеса — дает предложения по изменению существующих параметров продукта, услуги или проекта, а также по добавлению новых функций и опций. Особенно эта связь важна на рынке B2B, где покупатель решения (отдел закупок) чаще всего не совпадает с его пользователем (рядовые сотрудники).
Техподдержка как инструмент допродаж (upsell)
Качество поддержки влияет не только на повторные продажи, но и на появление новых клиентов. Чужие отзывы о том, что производитель хорошего решения игнорирует запросы пользователей вряд ли пройдут мимо тех, кто еще только интересуется ассортиментом аналогичных продуктов на рынке. И наоборот, решение, чьи клиенты говорят, что все их вопросы решаются буквально «на лету», получает всё большую популярность. Ведь потенциальным покупателям необходимо, чтобы бизнес работал с минимальным количеством сбоев, не влияющих на финансовые показатели.
Таким образом, техническая поддержка — это еще и инструмент повышения лояльности существующих и будущих клиентов.
Раз уж мы говорим о лояльности, то в сегменте поддержки можно выделить клиентскую и техническую. Вторая — обеспечивает решение именно технических проблем («у меня здесь не работает»), первая же работает над выстраиванием долгосрочных взаимоотношений с клиентами с целью повышения совокупного дохода, полученного от одного «контакта». Об их разнице мы уже подробно писали.
Структура поддержки
Для обеспечения лучшего уровня сервиса при сохранении разумных затрат на содержание отдела поддержки внутри него принято выделять несколько линий, разделяя между ними существующие обязанности.
Чаще всего можно выделить:
Часто в дополнительные линии (четвертую, пятую) выделяют представителей разработчиков и сторонних контрагентов, если в продукте или проекте задействованы чужие решения. Однако во многих компаниях ограничиваются лишь двумя линиями, относясь к остальным специалистам, как к партнерам по решению отдельных проблем.
Системы техподдержки
В современном мире поддержка, как и любая другая сфера взаимоотношения с клиентами, требует автоматизации — к этому подталкивает сам рынок и достаточно сложные процессы обслуживания. Клиенты привыкли, что даже в крупных ритейлерах или финансовых организациях их узнают по ID, моментально вспоминая историю взаимоотношений, и не требуют по 10 раз повторять одну и ту же историю. Того же они хотят и от сервиса в области B2B. Для удовлетворения этого клиентского ожидания компании используют программные инструменты — системы автоматизации класса helpdesk.
Системы автоматизации процессов поддержки значительно отличаются друг от друга. При выборе — важно не запутаться. Подробнее о том, как выбрать решение подобного класса читайте в отдельной заметке
Okdesk — удобная и функциональная система автоматизации техподдержки. Сотни компаний ежедневно используют лучшие практики в своей деятельности.
Понятие сопровождения программ для ЭВМ и баз данных: обзор правовых и практических аспектов
Понятие сопровождения программ для ЭВМ и баз данных (далее — ПО и БД) не определено законом, но на практике и в различных официальных документах сложилось достаточно однородное понимание этого процесса — к нему относится, прежде всего, разного рода обучение пользователей работе с продуктом и соответствующие консультации, настройка и адаптация продукта в среде пользователя, поддержание его работоспособности и исправление возможных ошибок, обновление, а иногда и модификация. Состав операций по сопровождению не имеет жестких универсальных границ, а гибко определяется договорами сторон. Важно отметить, что при наличии в составе действий по сопровождению модификации ПО и БД перед участниками сделки встает вопрос о принадлежности прав на модифицированный продукт.
Необходимо отметить, что распространенность сопровождения ПО на ИТ-рынке как формы сервиса влечет проникновение этого термина и в сферу юридических отношений, вследствие чего нередки становятся случаи, когда приходится соотносить с ним те или иные действия сторон договора либо правовые институты, что иногда может оказаться непростой задачей.
Особенно часто потребность в правовой квалификации сопровождения ПО и БД возникает в сфере интеллектуальной собственности, когда необходим учет интересов авторов и правообладателей при конструировании сделки. Для прояснения ситуации в настоящей статье будет произведен обзор категории сопровождения ПО в соответствии с установившимися практиками.
Что является сопровождением ПО
В федеральном законодательстве отсутствует понятие сопровождения ПО и БД (а равно и понятие «поддержка», которое обычно рассматривается как синоним). Вместе с тем на рынке сложилось определенное понимание перечня операций и обязательств сервисной организации, относящихся к сопровождению, притом что данный перечень является широким и продолжает расширяться по мере технологического прогресса. Это понимание основывается в том числе на ряде примеров операций по сопровождению, которые содержатся в различных официальных документах (в том числе подзаконных актах и нормативных актах регионального уровня), и отражается в договорной (контрактной) практике рынка.
Для начала предложим обобщающий взгляд на содержание сопровождения ПО и БД, а ниже поговорим подробнее о его отдельных элементах в контексте конкретных иллюстрирующих примеров. Итак, на рынке устоялись следующие типы сопровождения ПО с нижеследующим характерным наполнением:
Сразу отметим, что приведенный комплекс операций очерчивает границы сопровождения ПО и БД как теоретической категории. На практике же, в рамках конкретных договоров и техзаданий, сопровождение ПО и БД обычно представлено лишь какой-то частью этих операций, интересных и необходимых конкретному пользователю данного продукта с учетом особенностей его технологии, сервисной политики разработчика, объема потребностей и т. д. Таким образом, любой компонент представляет собой сопровождение ПО и БД как сам по себе, так и в связке с другими компонентами.
Распространенность двух выделенных типов сопровождения ПО и БД неодинакова. Первый, наиболее обычный тип, сводится к штатным операциям по поддержке, настройке, адаптации продукта и управлению им, не предполагая его творческую авторскую переработку на стороне исполнителя. Тем не менее иногда сервисной компании отводится более серьезная роль по расширению или изменению функциональности, созданию новых модулей, баз данных в составе продукта и т. п. — по сути, это отдельное направление деятельности, которое серьезно вклинивается в сферу авторского права. В силу последнего обстоятельства второй тип сопровождения обычно требует особых договоров сервисной компании не только с разработчиком, но и с клиентом, учитывающих возникновение в результате расширенного сопровождения новых объектов интеллектуальной собственности. И следовательно, такое сопровождение зачастую уже граничит с другими правовыми категориями (договор авторского заказа, лицензионный договор и др.) и онтологически отличается от обычной сервисной поддержки.
Раскрытие понятия сопровождения ПО в официальных документах
Теперь посмотрим, как отдельные операции по сопровождению ПО и БД из обозначенного перечня отобразились в тех или иных официальных документах.
1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком
1.1. Обучение работе с продуктом и его обслуживание в режиме диспетчерской связи.
К услугам, связанным с сопровождением, технической поддержкой, обновлением ПО и БД, отнесены, в частности:
Поддержка функционирования ПО и БД может включать в себя обучение или работу в режиме диспетчерской связи (п. 6.4.10.1).
1.2. Адаптация, настройка и дальнейшая техподдержка экземпляров с учетом особенностей среды пользователя.
Сопровождение может включать изменение программного продукта после поставки, обеспечивающее его работоспособность в измененных или изменяющихся условиях (среде), то есть модернизацию, позволяющую вносить изменения в эксплуатационную среду программного средства. Данные изменения должны быть внесены для сохранения работоспособности продукта в изменяемой среде. Например, операционная система может быть модернизирована и некоторые изменения должны быть внесены в продукт для его адаптации к новой операционной системе (п. 4.1).
1.3. Профилактика и устранение сбоев в работе пользовательских экземпляров.
Сопровождение может предполагать реактивное изменение программного продукта, выполняемое после его поставки для корректировки обнаруженных проблем (несоответствий, ошибок). Подобные изменения исправляют программный продукт для того, чтобы он соответствовал установленным требованиям (п. 4.3).
Также в рамках сопровождения возможна профилактическая модификация программного продукта после поставки в целях обнаружения и корректировки имеющихся в нем скрытых ошибок для предотвращения явного проявления этих ошибок при эксплуатации данного продукта (п. 4.11).
1.4. Прочие, обычно индивидуально обусловленные операции.
Стороны могут договориться о ряде иных необходимых клиенту операций по поддержанию ПО и БД в требуемом состоянии и облегчению работы с ним. Например, по улучшению дизайна, по корректному выводу из эксплуатации, созданию резервных копий и т.д. Приведем пример.
Сопровождение ПО и БД включает мероприятия по анализу качества, устранению выявленных ошибок, внесению изменений в ПО и документацию, извещение пользователей об изменениях, хранение образов установочных дисков используемого ПО (п. 6.2).
2. Расширенный тип сопровождения — дополнительная доработка (модификация) ПО и БД.
2.1. Модификация эталонных ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры.
Сопровождение может предусматривать модификацию программного продукта после поставки для повышения его рабочих характеристик, и тогда оно обеспечивает модернизацию (усовершенствование) продукта в интересах пользователя, уточнение соответствующих программных документов и его перепрограммирование для улучшения рабочих характеристик, сопровождаемости и других атрибутов программного средства (п. 4.10).
Результат успешного сопровождения ПО и БД, в частности, предусматривает (п. 6.4.10.2):
2.2. Модификация эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры.
В рамках антимонопольного дела процитирована конкурсная документация заказчика по аукциону на право сопровождения программного продукта, а именно: сопровождение — процесс поддержания работоспособности, а также улучшения, оптимизации и устранения дефектов существующей системы; в ходе сопровождения в систему вносятся изменения, с тем чтобы исправить обнаруженные в процессе использования дефекты и недоработки.
Состав работ по сопровождению ПО и БД в различных схемах обслуживания и контрактах
Как видим, ни закон, ни указанные выше официальные документы не определяют жесткого перечня операций по сопровождению ПО и БД. Причем, как уже было указано, в большинстве случаев в договоры включаются только некоторые элементы сопровождения, интересующие заказчика в контексте специфики имеющегося продукта, собственных сервисных ресурсов, опыта и т. п.
Законодательство также не лишает стороны договора возможности разбить весь комплекс операций (услуг и работ) по сопровождению ПО и БД на несколько «учетных единиц», т.е. товарных позиций, в отношении каждой из которых будут действовать различные договорно-правовые режимы и цены. Например, такая разбивка распространена при расширенном сопровождении, включающем модификацию ПО и БД, когда действия по его доработке (улучшению и/или индивидуализации функционала, созданию новых или расширению имеющихся БД и т.п.) выделяются в отдельную товарную позицию или даже в отдельный договор. Это бывает оправдано, ведь модификацией произведения признается его переработкой и имеет особый правовой режим, требующий согласования с разработчиком (пп. 9 п. 2 ст. 1270 ГК РФ) [10]. Но с другой стороны, в ряде случаев сопровождение ПО и БД сводится к минимальной техподдержке их работоспособности в той или иной форме при различных сбоях, и тогда товарная позиция по договору является узкой и монолитной.
Особенности сопровождения ПО и БД очень сильно зависят от свойств, которые приданы им разработчиком, и от тех правовых и маркетинговых политик, которые практикуются последним. Так, некоторые продукты существуют в свободном для использования онлайн-доступе без каких-либо требований к сопровождающим лицам, тогда как другие распространяются только через сертифицированные организации (дилеров, дистрибьюторов), наделенных специальными инструментами для сопровождения ПО и БД и/или предоставления легального доступа. В последнем случае состав операций по сопровождению ПО и БД также может быть распределен между разработчиком и дистрибьюторами самым различным образом. Частый случай: к деятельности разработчика по сопровождению ПО и БД относятся в основном модификация и обновление эталонного продукта в целях его развития (придание новых свойств, совершенствование функциональности), а к деятельности дистрибьюторов — более широкий спектр операций, исключая саму модификацию.
Можно привести следующие примеры из практики. Пример «широкого» содержания сопровождения ПО и БД — Приложение 4 к Письму Комитета финансов Санкт-Петербурга от 30.11.2010 N 01-02/3067 о финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 г. Согласно данному документу работы и услуги по сопровождению программных продуктов включают:
Надо сказать, что процитированный документ содержит подробную расшифровку почти каждого пункта описания работ и услуг, составляющих сопровождение. Так что границы его оказываются очень обширными, включая в себя десятки различных операций (установки, выгрузки, диагностика, коррекция, настройки, различные виды обучения и т.д.) [11].
В рамках судебного спора процитировано положение заключенного между участниками спора договора: «…Исполнитель обязуется оказать услуги по сопровождению прикладного программного обеспечения в объеме одного отчета для одного пользователя. Сопровождение — процесс улучшения (не ведущий к трудозатратам, более описанных в Приложении N 1), оптимизации и устранения дефектов прикладного ПО после передачи в эксплуатацию, обеспечение полноценной функциональности прикладного ПО, консультации пользователей» [12].
Заключение
В настоящей статье рассмотрены правовые и практические аспекты понятия «сопровождение программного обеспечения (программ для ЭВМ и баз данных)».
Данное понятие не регулируется в федеральном законодательстве.
На практике и в подзаконных актах к сопровождению ПО и БД относится обширный комплекс различных операций, которые можно сгруппировать в несколько направлений. Очень важно, что данный комплекс не является универсальным, неизменным и обязательным, а регулируется договорами между заказчиками и исполнителями. В ряде случаев в составе сопровождения проводится модификация ПО и БД, которая требует урегулирования вопроса прав на модифицированный продукт.
Наконец, учитывая стремительный темп развития информационных технологий, само понятие сопровождения ПО следует охарактеризовать как достаточно динамичное и отражающее самые различные тренды и перспективы.