Russian version
English version
ОБ АЛЬЯНСЕ | НАШИ УСЛУГИ | КАТАЛОГ РЕШЕНИЙ | ИНФОРМАЦИОННЫЙ ЦЕНТР | СТАНЬТЕ СПОНСОРАМИ SILICON TAIGA | ISDEF | КНИГИ И CD | ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ | УПРАВЛЕНИЕ КАЧЕСТВОМ | РОССИЙСКИЕ ТЕХНОЛОГИИ | НАНОТЕХНОЛОГИИ | ЮРИДИЧЕСКАЯ ПОДДЕРЖКА | АНАЛИТИКА | КАРТА САЙТА | КОНТАКТЫ
 
Информационный центр
 
Для зарегистрированных пользователей
 
РАССЫЛКИ НОВОСТЕЙ
IT-Новости
Новости компаний
Российские технологии
Новости ВПК
Нанотехнологии
 
Поиск по статьям
 
RSS-лента
Подписаться
Статьи и публикации

Контракт на аутсорсинг

Наталья Басина

Считается, что одна из самых сложных стадий при заключении соглашения о предоставлении услуг аутсорсинга - проведение переговоров и, в случае их успешного завершения, - составление контракта. По крайней мере, такого мнения придерживаются зарубежные эксперты, и прежде всего американские, выучившие слово «lawyer» третьим вслед за обязательными «mom» и «dad». Что же, во многом они правы: главная сложность взаимоотношений, возникающих на платформе аутсорсинга, состоит в разнообразии возможных коллизий и проблем, в то время как множество аспектов, которые следует учитывать сторонам, находится на стыке права, технологий и стандартов.

 Юрий Прохоров: «Наличие типовых документов существенно упрощает ход переговоров».Гэй и Эссингер, говоря в своей книге «Аутсорсинг изнутри» о составлении контракта сервис-провайдером, используют занятную аналогию: попробуйте предложить голодному крокодилу составить меню для ланча, пообещав во всем с ним соглашаться. Мало того, гуру теории и практики аутсорсинга уверены, что такой подход совершенно оправдан, а затраченные время и усилия вернутся сторицей.

По сути, уже на этапе подготовки контракта можно говорить о начале процесса «конструирования отношений» между сторонами. Впрочем, это не означает, что каждый раз придется, во-первых, изобретать велосипед, а во-вторых, приспосабливать его к российским условиям эксплуатации. По словам заместителя генерального директора компании WideXs Юрия Прохорова, все имеющиеся «типовые юридические разработки договоров, соответствующие и российскому праву, и зарубежным нормам, в ходе переговоров с заказчиком, как правило, удается „настроить" на конкретный проект. Это требует, разумеется, изрядных затрат времени и усилий. И все же наличие типовых документов существенно упрощает ход переговоров».

Итак, шаблоны все-таки есть, и они применимы. А раз так, имеет смысл прислушаться к зарубежным специалистам, утверждающим: тщательно проведенная подготовительная работа и грамотно составленный контракт способны существенно упростить взаимодействие сторон в дальнейшем.

Нет проблем?

Как все-таки обстоят дела в сфере контрактации аутсорсинга в России? И действительно ли грамотно проведенная подготовка контракта снимает все проблемы?

Директор Центра аутcорсинга Data Fort Юрий Самойлов прямо говорит: контракт не решает всех возможных проблем. Тщательная и грамотная подготовка контракта позволяет, по словам Самойлова, зафиксировать договоренности обеих сторон о возможных путях их решения на весь срок действия контракта. Однако, поскольку работа аутсорсера строится на взаимодействии прежде всего с людьми, то на субъективную оценку деятельности аутсорсера существенно влияет человеческий фактор. А значит, его невозможно не учитывать. «Мы стремимся управлять ситуацией и регулярно проводим мониторинг степени удовлетворенности заказчика на протяжении всего срока действия контракта, своевременно предпринимая действия по устранению неудовлетворенности», - говорит Самойлов.

По мнению директора департамента техподдержки и аутсорсинга компании «АйТи» Вячеслава Ермолова, составление аутсорсингового договора - процесс довольно сложный и длительный, однако благодаря этому появляется возможность расставить все точки над «i», предотвратив вероятность возникновения многочисленных конфликтов в будущем. «Однако совершенно очевидно, - подчеркивает Ермолов, - что предвидеть все ситуации и отразить их в договоре невозможно. У заказчика может возникнуть желание скорректировать правила игры во время реализации проекта, и это нередко происходит, поскольку более четко определить цели на практике проще. В таких случаях мы идем навстречу клиенту и вносим необходимые изменения в соглашение об уровне качества услуг (SLA[Service Level Agreement - соглашение об уровне качества услуг (или, реже, соглашение об уровне обслуживания), определяет взаимные ответственности провайдера ИТ-сервисов и пользователей этих сервисов. Цель  документа - дать качественное и количественное описание сервисов как с точки зрения провайдера, так и с точки зрения клиентов. Существенной частью SLA является каталог сервисов]), поскольку это соглашение является приложением к договору и его можно корректировать по согласованию сторон».

Руководитель направления ИТ-услуг компании «Микротест» Денис Матеев также полагает, что договор о предоставлении услуг аутсорсинга следует отнести к основополагающим факторам последующего успеха проекта: «Успех здесь в значительной мере зависит от того, насколько четко в контракте детализированы все его составляющие, и от того, насколько хорошо их осознал заказчик». По словам Матеева, далеко не всегда представители предприятий-заказчиков достаточно подготовлены для того, чтобы корректно сформулировать и поставить задачу, а тем более составить договор, квалифицированно отразив в нем все существенные аспекты. «Именно поэтому, выступая в качестве аутсорсера и, естественно, будучи заинтересованными в успехе выполняемых нами работ, мы постоянно вынуждены проводить предварительную работу совместно со специалистами предприятия-заказчика, - продолжает Матеев. - И я уверен, что такой подход является единственно правильным в том случае, если заказчик рассчитывает получить качественные профессиональные услуги, соответствующие его бизнес-задачам. К сожалению, многие российские заказчики и исполнители не понимают важности этого подхода. Отсюда - низкий процент успешных проектов».

 Вячеслав Ермолов: «В ходе контрактации значительное внимание следует уделять именно совместной разработке каталога сервисов и SLA».Вячеслав Ермолов («АйТи») отмечает: процедура формирования контракта легко разбивается на два ключевых этапа. Это разработка технико-коммерческого предложения (ТКП) и - собственно соглашения об уровне качества услуг. Понятно, что если в ТКП фигурируют значительные объемы технических средств, то на пути разработки SLA могут возникнуть некоторые препятствия. «Нередко заказчику бывает очень непросто определить необходимое качество предоставления сервисов либо потому, что в компании до сих пор метафора SLA не применялась вовсе, а качество услуг по техподдержке менялось от ситуации к ситуации, либо логика SLA присутствовала „негласно", неформально, то есть действовала на уровне передачи „из уст в уста", а не в виде явно прописанных формализмов, - говорит Ермолов. - Поэтому в ходе контрактации значительное внимание следует уделять именно совместной разработке каталога сервисов и SLA».

В этой связи директор по маркетингу «Квазар-Микро» Сергей Щербина напоминает: проект по передаче ИТ-сервисов на аутсорсинг может затрагивать функции администрирования, управления сбытом и поставками, финансового управления, управления ИТ-инфраструктурой и многие другие бизнес-процессы. А значит, и цели применения аутсорсинга могут быть самыми разными. Это и снижение затрат, и совершенствование бизнес-процессов, и освобождение ресурсов для более полного сосредоточения компании на своих ключевых компетенциях. А поскольку речь часто идет о жизненно важных для любой компании функциях, обе стороны должны корректно оценивать задачи, масштабы, этапы и риски проекта. Тем более, что, согласно оценкам исследовательской компании Gartner, одна из главных причин неудач аутсорсинговых проектов кроется как раз в отсутствии четкого понимания сторонами основных параметров проекта, рассогласованности ожиданий.

Подготовка

В своей работе «ИТ-аутсорсинг. Практическое руководство» Роб Аалдерс приводит семь обязательных элементов работы, предшествующей составлению контракта:

  • определение возможностей контракта;
  • описание;
  • due diligence (дословно - «должная осмотрительность»). Процесс проверки и подтверждения сервис-провайдером состояния ИТ-окружения, за которое он впоследствии будет нести ответственность;
  • подготовка «бумажного» варианта;
  • составление приложений и графиков;
  • решение спорных вопросов;
  • определение квалификационного уровня.

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

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

    В свою очередь, Сергей Щербина подчеркивает, что на этапе подготовки к заключению контракта критически важно определить еще и функции управления, которые останутся за предприятием-заказчиком. Это контроль за исполнением контракта и процедуры управления исполнителем, осуществляющим аутсорсинг. По мнению Щербины, на первом этапе должен быть проведен аудит имеющейся ИТ-инфраструктуры и бизнес-процессов, а также анализ готовности к передаче ряда бизнес-процессов на аутсорсинг, в результате чего выявляются «узкие места» перехода на новую схему работы. Таким образом появляется возможность разработать подробный план мероприятий по изменениям ИТ-инфраструктуры, нацеленных на оптимизацию стоимости, надежности и качества процессов, передаваемых на аутсорсинг, а также план необходимых организационных мероприятий по переходу на схему аутсорсинга.

     Денис Матеев: «Чем сложнее проект по аутсорсингу, тем больше свободы должно быть дано исполнителю».По оценкам Дениса Матеева, перед заключением контракта обязательно должны быть выполнены еще и «предпроектные изыскания», то есть определены цели проекта по аутсорсингу, ИТ-стратегия на текущий год и ближайшее будущее, а также желаемые (ожидаемые) результаты по выполнении работ. Кроме того следует определить критерии достижения результатов, согласовать план и время выполнения этапов работ проекта, включая график отчетности. «Необходимо исследовать ИТ-инфраструктуру, находящуюся в распоряжении заказчика, понять, как организована эксплуатация, изучить нормативные документы в области ИТ и ИБ, - рекомендует Матеев. - По результатам такого исследования и анализа ситуации обычно проводится ряд мероприятий по подготовке к проекту, например, разворачиваются системы мониторинга и управления, организуются рабочие места аутсорсинговых специалистов, осуществляются SLA-тесты и т. п.».

    Юрий Самойлов напоминает о важности подготовки соглашения об уровне качества обслуживания, регламентов и процедур взаимодействия, проработки штрафных санкций и всех вопросов, связанных с безопасностью и конфиденциальностью. А Вячеслав Ермолов отмечает, что заключению контракта обязательно предшествует инвентаризация парка оборудования, передаваемого на техническую поддержку аутсорсеру: «С помощью паспортизации объектов обслуживания заказчик и компания-аутсорсер оценивают масштаб передаваемого ИТ-хозяйства, что вместе с уровнем качества услуг техподдержки определяет стоимость контракта. Причем информация об оборудовании вносится в автоматизированную систему технической поддержки».

    Зоны ответственности

    Корректное разделение зон ответственности между сторонами - одна из самых тонких тем. С одной стороны, все выглядит крайне просто: нужно «лишь» обеспечить наличие SLA, где будут указаны зоны ответственности, варианты разрешения разногласий и штрафные санкции. «Для этого просто необходимо, помимо подробного описания предоставляемых услуг с соответствующими метриками, определить регламенты и процедуры взаимодействия специалистов заказчика и исполнителя, - говорит Денис Матеев. - И чем более детально и ясно все будет описано, тем с меньшим количеством проблем и конфликтов придется сталкиваться». По мнению Сергея Щербины, один из аргументов в пользу модели аутсорсинга как раз и состоит в возможности для заказчика получить четкие метрики и модели оценки эффективности бизнес-процессов. «В идеале, правильно составленный контракт позволяет заказчику и поставщику контролировать соблюдение этих метрик, не вмешиваясь в сам процесс, - подчеркивает Щербина. - Заказчик должен быть готов делегировать свои процессы, а поставщик услуг - отвечать за соответствие предоставляемой услуги указанным в контракте метрикам».

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

    Оптимальный срок

    Практически все эксперты оценивают средний срок составления контракта в три месяца. Впрочем, эта цифра достаточно условна и может довольно сильно варьироваться. Так, по словам Вячеслава Ермолова («АйТи»), срок заключения контрактов зависит от таких факторов, как объем техники, передаваемой на обслуживание, масштаб компании-заказчика, качество предоставляемых сервисов и даже уровень корпоративной культуры. «Поэтому оптимального срока для составления контракта не существует, - отмечает Ермолов. - В практике нашей компании небольшие договора подготавливались в течение 2-3 недель, крупные - до 3 месяцев».

    Денис Матеев («Микротест») подчеркивает, что сроки напрямую зависят от сложности проекта (размера ИТ-системы, списка и объема выполняемых услуг, ресурсов), а также от того, насколько выполнена заказчиком подготовительная работа. «Как правило, это занимает от 3 до 6 месяцев для проектов средней сложности». А по словам Сергея Щербины («Квазар-Микро»), подготовка значительного аутсорсингового контракта занимает от нескольких месяцев до года. «В мировой практике известны случаи, когда контракты готовят еще более длительное время, - рассказывает Щербина. - Правда, при этом речь идет о многолетнем стратегическом сотрудничестве, и суммы таких контрактов исчисляются сотнями миллионов долларов».

    С ним согласен и Юрий Прохоров (WideXs): «Для проектов „средней" сложности и соответствующей готовности заказчика период составления договора занимает от трех месяцев до одного года». При этом Прохоров отмечает, что при отсутствии такой готовности процесс может тянуться несколько лет, в течение которых уточняются и цели, и задачи, стоящие перед заказчиком. «В работе должен действовать главный принцип - если заказчик не знает проекта, надо не огорчаться, а помогать ему его разработать». Впрочем, Юрий Самойлов (Data Fort) уверен, что вопрос о сроках как таковой вообще не критичен, поскольку ключевую роль играет качество контракта и уровень его проработки. 

    Каким должен быть контракт

     Сергей Щербина напоминает: обе стороны должны корректно оценивать задачи, масштабы, этапы и риски проекта.Задача решена? Увы, на практике нередко случается так, что красиво «прописанные» правила приходится корректировать, а порой возникает необходимость еще и решать вопрос о том, как нащупать деликатный компромисс между «жестким контрактом» и контрактом, в котором были бы отражены все возможные изменения ситуации. И вот здесь начинаются частности. «На нынешнем этапе развития рынка, когда спрос значительно ниже предложения, мы готовы предлагать заказчикам гибкие условия контракта, чтобы развивать рынок и устанавливать длительные отношения», - говорит Юрий Самойлов. А по мнению Вячеслава Ермолова, одну из значимых ролей в аутсорсинговых проектах по оказанию услуг техподдержки играет сервис-менеджер. «Причем в идеале, - подчеркивает Ермолов, - для соблюдения равновесия интересов сервис-менеджер должен быть выделен как со стороны компании-аутсорсера, так и со стороны заказчика. Сервис-менеджеры наделяются широким кругом полномочий, и большинство ситуаций, не нашедших отражения в контракте, как правило, решаются этими специалистами в рабочем порядке».

    Сергей Щербина уверен: контракт на аутсорсинг должен соответствовать трем основным требованиям:

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

    Однако Денис Матеев напоминает: «Слишком многое зависит от характера проекта и задач, которые ставит заказчик. Если бизнес заказчика постоянно развивается, что, в свою очередь, накладывает ряд требований по развитию ИТ, то заключение „жесткого" контракта и, как результат, потенциальное отсутствие гибкости может повлечь ряд сложностей». В целом же, чем сложнее проект по аутсорсингу, тем больше свободы должно быть дано исполнителю. В таком случае задать альтернативные варианты развития гораздо труднее, и поэтому контракт должен определить, какие результаты, в том числе экономические эффекты, должны быть достигнуты при применении аутсорсинга, за счет каких ресурсов, в какие сроки, и не ограничивать жестко пути их достижения».

    Юрий Прохоров обращает внимание на то, что правила существуют как в юридической плоскости, так и в плоскости технических решений. «Учесть все возможные ситуации можно только в совокупности документов, детальность проработки которых существенно зависит от понимания заказчиком своих целей и задач, - утверждает Прохоров. - Практика показывает, что часто заказчик не представляет ясно этих целей и предполагает, что работа по принципу аутсорсинга как раз и даст возможность выяснить эти цели и возможности их достижения с помощью сторонней организации, предоставляющей сервис и инфраструктуру. Наличие опыта, соответствующих экспертов и практики у сторонней организации - это необходимое условие для возникновения доверия между двумя сторонами и достижения компромисса при заключении договора. Очень часто принцип „от прецедента" оказывается решающим».

    Брачный договор

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

    По словам Юрия Прохорова, возможность грамотного прекращения сотрудничества зависит от того, насколько детально проработан договор и сопутствующие документы, насколько договор позволил организовать контроль бизнес-процессов в ходе эксплуатации проекта. «Если контроль был достаточно полный, то выяснить спорные вопросы при прекращении сотрудничества удается без особых усилий, - считает Прохоров. - Однако если договор не позволил провести контроль в достаточной мере, то возникает много спорных позиций, точки зрения на которые у сторон весьма отличаются. Наверное, правильно дать общие рекомендации следующим образом: чем более точно обе стороны согласовали бизнес-процессы и иные условия при заключении договора, тем более просто осуществить „развод", даже в случае необходимости возмещения нанесенного ущерба одной из сторон. В этом смысле я сторонник не столько жесткого договора, сколько достаточно полно проработанного соглашения».

     Юрий Самойлов уверен, что вопрос о сроках как таковой вообще не критичен.Согласен с коллегой и Юрий Самойлов: «Процедура прекращения отношений зависит от того, насколько „промышленно" организован у аутсорсера процесс. В нормальном случае аутсорсер должен быть способен передать все процессы и функции заказчику в течение месяца. Для этого должна быть создана процедурная база и рабочий инструментарий. Гарантия выхода - прозрачность аутсорсера».

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

    Впрочем, Вячеслав Ермолов полагает: «Предоставление ИТ-сервисов само по себе предполагает долгую историю сотрудничества, и необходимо признать, что, заключая аутсорсинговый договор, сервисная компания в первую очередь ориентирована на его продление. Поэтому мотивация аутсорсера на выполнение всех обязательств сомнения не вызывает. С другой стороны, заказчик не заинтересован в смене аутсорсингового партнера, добросовестно оказывающего необходимый комплекс услуг. На настоящий момент рынок не знает скандальных примеров расторжения аутсорсинговых контрактов или разрыва партнерских отношений после их завершения».

    Чего не может контракт
    Сергей Теряев, руководитель технического центра компании «Релком.ДС»

    Сергей Теряев: «Самое важное состоит в выстраивании отношений и регулярной сверке „удовлетворенности сторонПри составлении контракта на аутсорсинг стоит помнить, что в любом, даже самом оптимальном случае все «рисковые моменты» все равно не будут учтены. Для примера попробуем рассмотреть ситуацию с уборкой офиса специализированной компанией. Скажем, в договоре написано: «Уборка мусора». При этом исполнители считают, что это означает очистку корзины от бумаг, а заказчик хочет явно другого. Это несоответствие выясняется через месяц работы. Заказчик читает специальную литературу, консультируется с профессионалами и осознает, что вместо ауттаскинга (то есть выполнения одной конкретной задачи по выносу корзин с мусором) ему нужно было оформлять договор об аутсорсинге (что он собственно и хотел, но не понял), то есть передаче уборочной компании бизнес-процесса по уборке помещений. В результате составляется новый договор, в котором указывается, что в офисе должно быть чисто. Вводятся понятия «чистоты как таковой», порядка проведения тестов и т. п. Казалось бы, все довольны. Однако еще через какое-то время заказчик опять не знает, что делать, так как «тетки-дядьки-с-пылесосами» круглые сутки ходят по кабинетам и гоняются за соринками даже во время совещаний. Договор снова переписывается, добавляются пункты о «режиме работы». Но через какое-то время выясняется что-нибудь еще. Например, «клининговые дядьки» ходят не в тех костюмах, ставят свои машины на офисной стоянке и мешают парковаться клиентам. По моему мнению, в договор не может быть внесено все просто потому, что никто не знает, что, когда и при каких обстоятельствах станет для руководителя компании (или для всей компании в целом) приоритетным. Универсальный ответ, который можно дать в данном случае, заключается в том, что заказчику надо нанять на работу того, кто понимает, как это нужно и можно сделать, и не давать этому человеку уйти. Что же касается правильного заключения контракта, то, по-моему, самое важное состоит в выстраивании отношений и регулярной сверке «удовлетворенности сторон». В принципе, многие знают, как это делать, и делают. 

    Ошибки

    «Типичные ошибки» при формировании соглашений аутсорсинга в России - слишком оптимистическая формулировка, учитывая нынешнее состояние этого сегмента рынка. По мнению Вячеслава Ермолова, «поскольку ИТ-аутсорсинг - довольно новая и самостоятельная услуга для отечественного ИТ-рынка, совершаемые ныне ошибки канут в небытие с накоплением первого опыта привлечения компаний-аутсорсеров. Впрочем, сегодня одной из грубейших ошибок при составлении договора остается игнорирование SLA как такового. В частности, иногда мы сталкиваемся с тем, что предлагаемый со стороны заказчика договор не отражает самой сути услуг технической поддержки ИТ-инфраструктуры и не содержит ссылки на SLA. Или SLA сводится к перечню регламента работ, которые обязан выполнить аутсорсер, и не отражает сроков и качества их исполнения. В этих условиях сервисная компания может оказывать услугу в удобный для нее срок, а не необходимый заказчику, и не нести за это никакой ответственности». С таким мнением согласны практически все эксперты: именно в правильном составлении SLA, по их мнению, состоит основная защита от ошибок.

    Юрий Прохоров подчеркивает, что большинство проблем возникает сегодня, как правило, из-за отсутствия многофакторного анализа условий договора и бизнес-процессов в последующей эксплуатации. Кроме того, следует учитывать: вероятность раздоров между сторонами высока еще и потому, что сама по себе методология аутсорсинга в России пока не прижилась, а значит, исполнителям нередко приходится самим проходить весь путь по проработке контрактов с нуля. Денис Матеев говорит о наиболее типичных ошибках, которые до сих пор допускают участники рынка и их заказчики:

  • стратегии бизнеса и ИТ не увязаны на стороне заказчика, поэтому задачи проекта по аутсорсингу неясны;
  • обязанности сторон четко не определены;
  • вопросы ценообразования неявно указаны в контракте (не показана используемая ценовая модель);
  • не описаны регламенты и процедуры взаимодействия специалистов заказчика и исполнителя.
    ***

    Юристы и адвокаты все еще не главные люди в сфере информационных технологий в России. Однако трудно игнорировать тот факт, что успех многих проектов ИТ-аутсорсинга в стране в ближайшие годы будет зависеть не столько от уровня компетенции исполнителей и применяемых ими решений, сколько от того, в какой степени профессиональными, четкими, непротиворечивыми и «прозрачными» будут договоры о предоставлении услуг, заключаемые между сторонами.


  •   Рекомендовать страницу   Обсудить материал Написать редактору  
      Распечатать страницу
     
      Дата публикации: 29.02.2008  

    ОБ АЛЬЯНСЕ | НАШИ УСЛУГИ | КАТАЛОГ РЕШЕНИЙ | ИНФОРМАЦИОННЫЙ ЦЕНТР | СТАНЬТЕ СПОНСОРАМИ SILICON TAIGA | ISDEF | КНИГИ И CD | ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ | УПРАВЛЕНИЕ КАЧЕСТВОМ | РОССИЙСКИЕ ТЕХНОЛОГИИ | НАНОТЕХНОЛОГИИ | ЮРИДИЧЕСКАЯ ПОДДЕРЖКА | АНАЛИТИКА | КАРТА САЙТА | КОНТАКТЫ

    Дизайн и поддержка: Silicon Taiga   Обратиться по техническим вопросам  
    Rambler's Top100 Rambler's Top100