Управление отношениями с поставщиками и вендорами

Лекция 28 Управление отношениями с поставщиками и вендорами Аннотация Ознакомление с основами взаимодействия с клиентами и партнерами в процессе решения задач управления жизненным циклом ИТинфраструктуры предприятия. Также в лекции присутствует перечень принятых сокращений. Подробнее о нём в Приложении 1. Управление отношениями Отношения. Что это? Часто мы слышим «у меня отличные отношения с…», «у него не сложились отношения...». Насколько отношения с окружающими влияют на нашу профессиональную жизнь? Как это происходит, и что необходимо делать, чтобы сделать отношения с людьми и компаниями своими помощниками, а не противниками в жизни и работе? Отношения и человеческие коммуникации – основные навыки в деятельности менеджера и руководителя. Развитие этих навыков – основа успеха в профессиональной и личной жизни. Постараемся разобраться в сути предмета и дать практические рекомендации. Подробнее о систематизации отношений в Приложении 2. Решение конфликта вокруг ИТ–пример вовлечения Рассмотрим крупную компанию, деятельность которой связана с торговлей. Компания занимается логистикой и обладает своей автоматизированной системой. Коммерческий директор привел некую компанию, которая, по его мнению, лучше всех может выполнить работу по автоматизации процесса его деятельности. В прошлом он с ней успешно работал, и достиг, по его словам, выдающихся результатов. Однако эксперты ИТ- департамента и ИТ- директор уверены, что предлагаемая система по 1 ряду технических причин непригодна и, к тому же, устарела. Налицо конфликт. Как сделать так, чтобы коммерческий директор решил свою задачу и остался доволен, а ИТ- директор и его сотрудники с удовольствием принимали участие в этом проекте? Основные шаги, в данном случае могут быть следующими. Несмотря на потенциальные проблемы, ИТ-директор соглашается на данный проект, тем самым постепенно располагая к себе и к своим решениям коммерческого директора. Спорить с коммерческим директором в такой ситуации – значит нажить себе врага. С коммерческим директором необходимо договориться о поддержке в процессе внедрения данной системы. ИТ-директору следует придерживаться следующей стратегии: мы внедряем автоматизированную систему, но с необходимыми для нас доработками со стороны исполнителя. Далее ИТ-директору необходимо оценить необходимые ресурсы (временные, денежные, человеческие) для внедрения системы. При этом в оценку надо заложить максимальное количество необходимых улучшений и доработок системы. Все предполагаемые решения необходимо вынести на совет директоров (правление). Перед этим желательно вынести этот вопрос на заседание комитета по ИТ с обязательным приглашением коммерческого директора для участия в нем. Вовлечение коммерческого директора в работу комитета по ИТ повысит его лояльность к предлагаемым ИТ-директором решениям, и их проще будет согласовать. Если комитета по ИТ в компании нет, необходимо его создать и проводить регулярно. Чтобы повысить лояльность сотрудников по отношению к внедряемой системе, необходимо мотивировать их за счет средств проекта, объяснить, что мы существенно дорабатываем и расширяем систему, а также вовлечь их в процесс написания технических заданий на доработку системы. 2 Профессиональное окружение CIO Давайте более подробно рассмотрим первую систематизацию отношений – по профессиональному окружению. Люди, занимающиеся одинаковой профессиональной деятельностью, исторически склонны объединяться в сообщества по профессиональному принципу. Отношения с подчиненными. Создавайте рабочую, дружескую атмосферу в коллективе, приучайте сотрудников к конструктивному общению. Отношения с регуляторами (чиновниками). Мы рекомендуем исключительно деловые отношения с регуляторами. Чиновников надо обеспечивать необходимым объёмом информации, позволяющим выполнять их работу. Однако не стоит забывать, что для эффективного привлечения и удержания дефицитных специалистов необходимо понимать их мотивацию. Например, одной из самых «горячих» позиций рынка труда в сфере ИТ остаются консультанты SAP. Сегодня сегмент SAP-специалистов составляет около 5% от всего объема рынка кадров. Конечно, интересы специалистов существенно различаются в зависимости от выполняемой ими роли. Например, сотрудники проектных команд («разработчики») больший интерес проявляют к сути проектных задач и к коллегам — им крайне важно работать в окружении профессионалов. Кроме того, у них более высокие требования к размеру совокупного дохода. Отношения с коллегами-руководителями. Выстраивание отношений с коллегами, основанных на доверии и взаимопонимании - одна из основных задач CIO. Для этого используются различные методы, часть из которых описана в главе «Профессия CIO». 3 Самое страшное в этих отношениях – появление внутреннего конкурента ИТ-службы. Часто выделение различных направлений и разделение на управленческое, производственное, развитие и сопровождение без общего квалифицированного управления приводит к серьезной деградации функции или неэффективному использованию ИТ. Отметим, что вместе с низким уровнем корпоративной культуры это может стать началом конца бизнеса особенно на высококонкурентных, розничных рынках. Второй важный момент в отношениях с коллегами – проблема доминирования. Финансовые, технические директора, руководители службы безопасности и прочие руководители часто считают работу CIO простой и пытаются либо занять позицию сверху по отношению к CIO в иерархической структуре компании, либо перетянуть на себя часть функциональных обязанностей вместе с ресурсами. Что делать в таких случаях? Во-первых, не ввязывайтесь в прямой конфликт. Докажите свою состоятельность и профессионализм через достижение быстрых результатов. Quiсk wins – это лучший «ответ» CIO. Ищите узкие места в бизнесе, «расшивайте» их с использованием современных технологий, помогайте бизнесу достигать бизнес-результатов, не тратя время и ресурсы на склоки внутри компании. Формируйте свой образ как профессионального менеджера и специалиста в области управления предприятием, а не «хитрого политикана», искушенного в корпоративной борьбе. Во-вторых, если ваш коллега уже совсем «распоясался» – можно сделать тактический шаг назад. Отдайте на время область ответственности и ресурсы. Ведь в 90% случаев тот, кто на них претендует, слабо разбирается в предмете. У каждого должен быть шанс провалиться – пусть он поруководит, раз очень хочет. Мы с вами знаем, что это совсем не так просто, как кажется. Зато потом, когда все увидят результаты его управления, можно будет вернуть все назад. 4 Отношения с акционерами, инвесторами и руководителями. Как правило, акционеры и руководители компании требуют прозрачных целей использования ИТ, синхронизированных с стратегическими целями бизнеса и демонстрации ценности, которую использование информационных технологий приносит компании. О методах построения адекватной ИТстратегии и подходах к демонстрации ценности ИТ мы рассказали в главах «ИТ-стратегия» и «Ценность ИТ». Основой для общения на уровне руководства компании и собственников бизнеса может быть вовлечение CIO в работу структур операционного и стратегического управления бизнесом. Как отличить акционеров и инвесторов от ген. директора? Акционер ИТ — это физическое, юридическое лицо (в том числе акционерное общество), организация (в том числе не имеющая статуса юридического лица, но обладающая гражданской правоспособностью в соответствии с законодательством иностранного государства), муниципальное образование, которое владеет одной или несколькими акциями в капитале акционерного общества. Инвестор ИТ — лицо или организация (в том числе компания, государство и т. д.), размещающие капитал, с целью последующего получения прибыли (инвестиции). Управление отношениями с поставщиками и вендорами Принципы построения взаимоотношений с ИТ- поставщиками В соответствии с рекомендациями ITIL, «цель управления поставщиками и предоставляемыми ими сервисами состоит в обеспечении непрерывного уровня качества ИТ-сервисов для бизнеса». Однако необходимо смотреть на этот вопрос несколько шире рамок ITIL. Для СIO цель управления поставщиками состоит также и в том, чтобы упростить и сделать более эффективными не только процессы взаимодействия между ИТ-подразделением и его поставщиками, но и 5 логично встроить разнообразные услуги и продукты поставщиков и вендоров в единую схему процессов предоставления качественных услуг бизнесподразделениям и при этом оптимизировать затраты компании и стоимость услуг ИТ-подразделения для внутренних клиентов. В целом, при построении взаимоотношений с ИТ-поставщиками необходимо опираться на два общих принципа: • Принцип оптимизации политик взаимодействия • Принцип взаимного баланса интересов заказчика и поставщика Подробнее о этих принципах в Приложении 3. Чем более сложные задачи решаются (от построения ИТ- инфраструктуры, до автоматизации бизнес-процессов), тем с большим уровнем неопределенности и количеством случайных факторов придется столкнуться ИТ-директору. Поэтому, в случае таких взаимоотношений, помимо более серьезных проверок поставщик, а на надежность, компетентность и т.д., необходимо опираться на 2 дополнительных принципа: • Принцип партнерства • Принцип соответствия размеров Подробнее о этих принципах в Приложении 4. Типы и виды поставщиков Если коротко по Ожегову, то «поставщик — лицо, организация, поставляющие какие-нибудь материалы, товары». Поставщиком может быть как внешняя компания, предоставляющая товары, работы, услуги, в соответствии с заключенным договором, так и внутреннее подразделение компании. Заметим, что в качестве ИТ поставщика может также выступать физическое лицо (фрилансер, внештатный работник), которого организация 6 нанимает только для выполнения определённого перечня работ без заключения долговременного трудового договора. Вендор (англ. vendor) — это поставщик брэнд-продуктов и услуг, выпускающий их под своей торговой маркой. В ИТ-среде термин «вендор» как правило, применяется для идентификации компании – разработчика оборудования и программного обеспечения, отличая тем самым от его партнеров, которые зачастую выступают в роли реселлеров (поставщиков) программного обеспечения. Существует также термин «независимый вендор программного обеспечения», (Independent Software Vendor, ISV) который применяется к компаниям, специализирующихся на создании или продаже программного обеспечения. Value-added reseller (VAR) — это компания, которая модифицирует/расширяет возможности уже существующего продукта (т.е. создает добавочную стоимость), а затем перепродает его, извлекая прибыль из создаваемой добавленной стоимости. Например, термин VAR широко используется в качестве определения производителей компьютеров, которые закупают отдельные комплектующие и на их основе собирают готовые компьютеры. Аутсорсинговая компания — это специализированный поставщик услуг, которые предусматривают исполнение переданных такой компании определённых бизнес- процессов или производственных функций организации заказчика. Роли и типы ИТ-поставщиков Перед тем, как говорить об общих принципах построения взаимоотношений с поставщиками, полезно посмотреть, в каких ролях предстают перед заказчиками ИТ-поставщики. ИТ-поставщик, а можно рассматривать как: 7 магазин, в который приходят купить пусть дорогие, но • необходимые товары; сервисную структуру, которая оказывает компании определенные • услуги; собрание • компетенций и экспертизы, которое можно использовать в случае недостатка компетенций внутри компании; исследовательскую лабораторию, которая может разобраться со • сложной проблемой, беспокоящей компанию; бизнес-партнера, с которым нужно выстраивать отношения не в • плоскости поставщик-потребитель, а как с компанией, которая вместе с вами работает над единой задачей. В зависимости от того, в какой роли выступает перед вами ИТпоставщик, по-разному будут выстраиваться отношения с ним. В одном случае CIO может и даже должен жестко требовать от поставщика соблюдения простых правил работы (например, когда он выступает как «магазин»), а в другом случае выстраиваются отношения доверия равных партнеров. Дело в том, что поставляемые продукты и услуги удобно разделять на два типа: • закупки простых продуктов и в некоторых видов простых услуг; • приобретение сложных продуктов или средних по сложности и комплексных услуг. При поставках этих двух типов поставщики выступают в различной роли, и взаимоотношения должны выстраиваться по-разному. Поэтому удобно аналогично делить ИТ-поставщиков. ИТ-поставщик типа 1 – это поставщик простых продуктов (типовое оборудование, простое ПО) и в некоторых видов простейших услуг. При поставке таких продуктов и услуг от поставщика требуется минимальный уровень собственной экспертизы в области ИТ, и создаваемая поставщиком 8 при такой работе добавочная стоимость находится в области логистики и понимания того, как работают вендоры. ИТ-поставщик типа 2 – это поставщик сложных продуктов или средних по сложности и комплексных услуг. Такие поставщики интересны прежде всего своей собственной экспертизой в области ИТ и уровнем предоставляемых услуг. Стандарт качества ISO-9000 Некоторые организации требуют от своих поставщиков наличие сертификатов на соответствие стандартам ISO-9001 или 9002. Сертификат, как правило, служит подтверждением того, что поставщик располагает соответствующей системой качества, эффективность которой регулярно оценивается независимыми аудиторами. Иными словами, цель системы управления качеством ИСО 9001 состоит в том, чтобы создать набор требований, соблюдение которых поможет гарантировать высокое качество работы и надёжность конкретного предприятия как поставщика и партнёра. Подробнее о стандарте качества ISO-9000 в Приложении 5. Процесс управления поставщиками Управление поставщиками (Supplier Management) - процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства. Построение системы управления поставщиками CIO должно начинаться с анализа требований законодательства и корпоративных стандартов. Очень важным является интегрирование процесса Управления поставщиками во все стадии жизненного цикла услуг, так как поставщики играют огромную роль в предоставлении услуг. Промежуточные цели процесса Управления поставщиками: 9 • получение ценности за потраченные бизнесом деньги; • обеспечение того, что все основополагающие контракты и соглашения с поставщиками соответствуют требованиям бизнеса, требованиям SLA и SLR; • управление взаимоотношениями с поставщиками; • управление производительностью поставщиков; • ведение переговоров и заключение контрактов с поставщиками, а также управление ими внутри жизненного цикла услуг; • управление политикой поставщиков и поддерживающей Базой поставщиков и договоров. Управление поставщиками следит за тем, чтобы поставщики выполняли свои обязательства по контрактам - достигали целевых показателей в оговоренные сроки. Центральным репозитарием для хранения информации является База поставщиков и договоров. База поставщиков и договоров (Supplier and Contract Database или SCD) - база данных или структурированный документ, используемый для управления договорами поставщиков на протяжении всего их жизненного цикла. SCD содержит ключевые атрибуты всех договоров с поставщиками. SCD должна формироваться вместе с четко определенными ролями и ответственностями, как показано на рисунке 2. 10 Рисунок 2 - База поставщиков и договоров SCD Деятельность по проектированию и развитию новых технологий не должна быть изолированной, так как влияет на другие услуги, системы управления, инструменты, архитектуры, процессы и т.п. Основными рисками для Управления поставщиками являются недостаточность информации, плохо налаженный обмен информацией между поставщиками и бизнесом, некорректные или невыполнимые цели, нехватка ресурсов и финансового обеспечения. 11 Планирование и организация процесса Процесс управления поставщиками может рассматриваться в тесной связи со сквозным процессом «от закупки до оплаты» и предусматривает прохождение следующих этапов. Определение потребностей. Процесс начинается со сбора и формализации требований. Перед тем как привязать требования к статьям бюджета, CIO и группа ИТ. - планирования делают оценку потребностей по объемам и денежному эквиваленту, учитывая, что первичные требования есть разных видов. Определение целей планирования – желаемого состояния предприятия и его положения на рынке. Разработка требований к поставщику и формирование перечня поставщиков. Анализ проблем – фактического исходного положения дел и по окончанию планового периода. Этот этап разработки перечня критериев, по которым разные поставщики будут сопоставляться друг с другом. Далее мы должны выбрать какие закупки и каких оптимальных поставщиков мы можем выбрать. Оценка и выбор поставщика. Поиск альтернатив – выявление возможных вариантов развития по различным сценариям. На этом этапе проходит оценка и выбор поставщика путем либо на конкурсной, либо не на конкурсной основе. Выбор поставщиков делится на два этапа: поставщик ПО и поставщик услуг по внедрению. Идет тестирование поставщиков для наилучшего понимания с кем вам приходиться сотрудничать. Определение условий и заключение договоров, определение механизмов мониторинга и контроля исполнения договорных обязательств. Заключение проекта договора поставки происходит по определенным правилам. В этапе описан порядок заключения договора поставки, возможные проблемы, сроки и особенности заключения договора поставки с поставщиком. 12 Мониторинг и контроль исполнения договорных обязательств, и управление изменениями (новыми требованиями). Водятся данные в реестр и проверяется статус исполнения в соответствии с простыми правилами, описанными в договоре. Приемка и закрытие работ по договору. Происходит подписание Акта приёмки сдачи работ. Обработка платежей. Это последний этап процедуры. Производится оплата по договору. Процесс управления поставщиками может рассматриваться в тесной связи со сквозным процессом «от закупки до оплаты». Этапы процесса управления поставщиками: 1. определение потребностей; 2. разработка требований к поставщику и формирование перечня поставщиков; 3. оценка и выбор поставщика; 4. определение условий и заключение договоров, определение механизмов мониторинга и контроля исполнения договорных обязательств; 5. мониторинг и контроль исполнения договорных обязательств, и управление изменениями (новыми требованиями); 6. приемка и закрытие работ по договору; 7. обработка платежей. Определение потребностей Процесс управления поставщиками начинается со сбора и формализации требований. Требования могут поступать либо от бизнеса (прикладные запросы на автоматизацию и модернизацию бизнес процессов), либо от сотрудников ИТ-департамента и проектных рабочих групп (инфраструктурные запросы на обновление и развитие ИТ- инфраструктуры). 13 Разработка требований и формирование перечня поставщиков Общий перечень поставщиков по каждой группе статей бюджета, или перечень, подготовленный специально для проведения конкурса, называют «длинным списком», из которого будет впоследствии формироваться перечень потенциальных поставщиков, так называемый «короткий список». На этом этапе должен быть разработан перечень критериев, по которым разные поставщики будут сопоставляться друг с другом. Как мы указывали выше, всех ИТ-поставщиков и закупки в ИТ удобно разделить на два вида: закупки простых продуктов (типовое оборудование, простое ПО) • и некоторых видов простых услуг (поставщики типа 1); приобретение сложных продуктов или средних по сложности и • комплексных услуг (поставщики типа 2). Этим двум типам продуктов и услуг соответствуют два подхода к выбору: • выбор по критерию минимальной цены из «короткого списка»; • выбор через сложный и многокритериальный анализ различных характеристик продукта и услуги. Выбор поставщика типа 1 В случае закупки простых продуктов у поставщиков типа 1 формирование «короткого списка» и выбор поставщика проходит по укороченному перечню параметров/требований: • репутация поставщика и наличие соответствующих прав, сертификатов (от вендоров) и, в ряде случаев, экспертизы; • финансовое состояние, опыт поставок и репутация. В короткий список попадают компании, которые отвечают выше приведенным требованиям. Далее выбор окончательного поставщика идет 14 только по цене, и главная задача при этом – оптимизация расходов на ИТ. Причем на поставщиков можно оказывать давление в отношении цены, так как рынок таких услуг велик, и заменить одного поставщика на другого достаточно просто. Выбор поставщика типа 2 При работе над сложными решениями, критичными для бизнеса, или касающимися прикладных задач, отношения с поставщиком долгие, и важно их правильно выстроить. В этом случае, помимо вышеприведенных требований к ИТ-поставщику, должны быть четко сформированы расширенные требования, которые включают гораздо более подробные параметры/требования: • повышенные требования к финансовой устойчивости; • экспертиза поставщика и квалификация сотрудников поставщика (в том числе и в дополнительных услугах); реальный и доказанный опыт работы поставщика или требования • к организации референс-визитов и предоставления информации; знание и понимание компании-заказчика и рынка, на котором он • работает; • срок работы на рынке и в отрасли, регалии, партнерские статусы • география точек присутствия; • требования к проведению обучения (при необходимости) и и т.д.; другим дополнительным услугам и пр. В случае выбора сложного продукта или услуги понять, кто является оптимальным поставщиком, намного тяжелее. В этом случае необходимо применение таких инструментов, как «длинный» и «короткий список» и «матричной» модели оценки поставщиков, с присвоением весов каждому из заданных параметров. 15 Оценка и выбор поставщиков В управлении поставщиками одной из сложных и важных задач является выбор поставщиков. Здесь есть два различных пути: проведение конкурса и выбор поставщика не на конкурсной основе. В случае организации конкурса компания (организатор конкурса) назначает Рабочую группу (куда ИТ-специалисты входят наравне с другими представителями бизнес-подразделений) и Конкурсную комиссию (куда входит CIO), которая и несет ответственность за результаты конкурса. Рабочая подготовленным группа в ходе подготовки ИТ-подразделением конкурса «длинным знакомится списком», с проводит сопоставление каждого с требованиями к поставщику и формирует «короткий список» потенциальных поставщиков для приглашения к участию в конкурсе. Конкурсы бывают одноэтапные и двухэтапные. Если говорить о внедрении сложных бизнес- приложений, конкурс, как правило, является двухэтапным, с предварительным квалификационным отбором. • первый этап - выбор поставщиков программного обеспечения и выбор ПО по конкретным функциональным и архитектурным требованиям и общим и техническим требованиям; • второй этап - выбор поставщика услуг по внедрению. Для большинства случаев выбора поставщика типа 2 рекомендуются двухэтапные конкурсы. На основании результатов анализа полученной от поставщиков информации о соответствии функциональным и техническим и общим требованиям, а также по результатам референс-визитов Рабочая группа готовит рекомендации для Конкурсной комиссии, которая принимает окончательное решение о выборе победителя. После принятия решения о выборе победителя может быть подписан протокол о намерениях (хотя это не обязательно и практикуется не всегда). 16 Протокол о намерениях необходим для фиксации того факта, что стороны достигли определенных договоренностей и начинают двигаться в сторону заключения контракта. Необходимо отметить, что конкурсные процедуры сами по себе не являются панацеей: «практика тендеров дает частичное решение проблемы – уровень поставщиков и связанные с этим риски часто не учитываются или учитываются не полностью. Без соответствующих мировой практике процедур оценки и отбора поставщиков мы обречены на нерациональные затраты при выполнении контрактов – и чем крупнее контракт, тем выше эти затраты». Таблица 3. Построение взаимоотношений с поставщиками различных типов. Взаимоотношения с Взаимоотношения с поставщиком типа 1 поставщиком типа 2 Небольшие Высокие Не нужно Необходимо Конкурс Открытый Закрытый Этапы конкурса Одноэтапный Двухэтапный Характеристики Риски Выстраивание партнерских отношений Использование Подходы к выбору Выбор из которого матричной системы списка, по цене оценки по большому количеству Центральное звено аппарата планирования – отдел планирования, в функции которого входят разработка перспективных и текущих планов, согласование их с производственными подразделениями, корректировка и уточнение плановых показателей, контроль за их выполнением и систематический анализ работы предприятия и его подразделений. 17 Связь процесса управления поставщиками с другими процессами ITIL В соответствии с положениями ITIL рекомендуется рассматривать процесс управления поставщиками во взаимодействии с другими ITIL процессами, которые в той или иной мере уже затрагивались в предыдущих разделах. В частности: • управление качеством (Quality management); • управление уровнем ус луг (Service Level Management, SLM); • управление финансами (Financial Management for IT Services, • управление проектами (Project Management); • управление ИТ-Активами (IT Assets Management). FIN); Контроль состояния работы с поставщиками Ведение учета с поставщиками и подрядчиками – это важнейший элемент системы управления взаимоотношениями с ними. Такой учет может вестись различными способами. Наиболее предпочтительный вариант – ведение такого учета в рамках общей системы бюджетирования расходов на ИТ. В случае отсутствия системы бюджетирования можно использовать простые таблицы: • реестр поставщиков и договоров; • реестр счетов от поставщиков и оплаты; Но в любом случае, учет должен фиксировать: • с какими поставщиками и вендорами заключены договора; • когда и на какой срок; • какова задача, которую решает поставщик и вендор; • какой объем оплаты соответствует заключенным договорам и ИТ бюджету, в какие сроки, в какой мере эти договора отвечают корпоративным требованиям; 18 какова доля каждого поставщика в текущем объеме поставок ИТ • оборудования, программного обеспечения материалов, работ и услуг; какова история взаимоотношения с каждым их поставщиков, как • они попали в портфель поставщиков ИТ; какова • задолженность компании перед поставщиками и вследствие чего она возникла. Даже если общая политика закупок в компании не обязывает проводить конкурсы по выбору поставщиков, и если в ИТ-подразделении уже есть привязка поставщиков к статьям бюджета, для дальнейшего планирования работы по процессу управления поставщиками, CIO необходимо регулярно проводить анализ состояния взаимоотношений с существующими поставщиками, проводить оценку их возможности выполнять контрактные обязательства. Выбор поставщика не на конкурсной основе Конкурсы – это важный элемент процесса выбора, однако опыт российских ИТ-директоров свидетельствует, что в рамках конкурсных процедур результате невозможно многие провести ИТ-директора детальную оценку применяют поставщиков. конкурс только В как техническую процедуру, а весь выбор поставщика ведут заранее. Более того, именно в предварительной работе с потенциальным победителем тендера они видят залог будущего эффективного партнерства. То есть, по сути, при таком подходе победитель тендера должен быть понятен CIO еще до его начала, а сама процедура тендера может помочь детально согласовать ожидания обоих партнеров и повлиять лишь только на финансовую сторону взаимоотношений. Подробнее о выборе поставщика не на конкурсной основе в Приложении 6. 19 Определение условий и заключение договоров Прежде всего, CIO необходимо четко оговорить с юристами компании и финансовыми службами зоны ответственности при подготовке договоров. Все договора, которые относятся к деятельности ИТ (на любые виды ИТуслуг и поставку ИТ-оборудования и материалов), должны готовиться в рамках ИТ- подразделения. Если говорить о договорах с поставщиками типа 2, то практика, когда договора, относящиеся в ИТ., готовятся бизнес- подразделениями не может быть признана успешной. Специалисты бизнес - подразделений не могут учесть все нюансы и тонкости хода проекта и взаимодействия с подрядчиком, поскольку не являются в этом профессионалами. Переговорный процесс. Заключению договора предшествует переговорный процесс. В случае договора с поставщиком типа 1 он, фактически сводится к минимуму. Но в случае построения взаимоотношений с поставщиком типа 2 переговорный процесс становится важнейшим элементом построения долгосрочных взаимоотношений. В этом случае качество договорного процесса – очень важный момент. В современном мире времени постоянно не хватает, надо двигаться все быстрее, в результате из поля зрения выпадают важные вопросы формализации достигнутых договоренностей. Но чем качественней будет построен договорной процесс, тем легче будет жить в дальнейшем. Тщательная подготовка к переговорам с поставщиками и грамотное составление договоров позволяют реализовать проекты и организовывать поставки с минимальными для компании рисками, избегать неприятных ситуаций и результативно отстаивать свои права в суде. В частности, для успешного ведения переговоров по контракту нужно заранее определиться со следующими вопросами: • каковы возможные цели поставщика в переговорном процессе; 20 • какие пункты проекта договора вызвали дополнительные вопросы со стороны юридических и финансовых служб (в частности, порядок формирования стоимости закупок, размеры скидок, возможные штрафные санкции, порядок оплаты, другие возможные условия); • насколько полно прописаны требования в техническом задании, как приложении к договору? Что конкретно предполагается сделать; • каковы риски вследствие неполноты и недостаточной конкретности технического задания; • что может помешать выполнению договора? Какие необозначенные ранее риски несет компания по данному договору; • кто и как будет контролировать объем и сроки выполнения работ; • как будет оцениваться качество выполненных работ и представляемых результатов; • если контракт не предусматривает фиксированной стоимости, как будут контролироваться и подтверждаться трудозатраты; • как и кем будут согласовываться возможные изменения и дополнения к договору; • как будут приниматься результаты работ; • какие другие ограничения и условия должны быть внесены в договор и приложения к нему. Данный перечень можно взять за основу для подготовки перечня вопросов для подготовки и проведения переговоров с поставщиком, добавив к нему свои специфические вопросы. Структура переговоров должна быть понятна обеим сторонам – в процессе переговоров должны укрепляться доверие и открытость. Если установлены доверительные отношения, добиться согласования юридических и стоимостных характеристик контракта гораздо проще. 21 Заключение контракта После проведения переговоров стороны приходят к заключению контракта. Независимо от уровня взаимоотношений с поставщиком и степени влияния личностных и субъективных факторов, контракт с ним должен быть максимально жестким и в максимальной степени фиксировать все нюансы взаимоотношений. В случае возникновения спорных моментов при обсуждении договоров на стадии подписания рекомендуется подписывать протоколы разногласий, которые позволяют свести спорные условия договора к «общему знаменателю», устраивающему все стороны. Важные моменты, на которые надо обратить внимание при составлении контракта: • не абстрактное качество, а конкретные SLA или сформулированные иным образом параметры качества и предоставления продуктов и услуг; • определение механизмов мониторинга и контроля исполнения договорных обязательств; • штрафные санкции в случае нарушения сроков и качества предоставления продуктов и услуг; • механизмы управления изменениями и новыми требованиями; • действия при возникновении проблем с командой поставщика, что, к сожалению, случается часто; • условия пролонгации и закрытия договора. Для договоров, которые предполагают выполнение проектных работ, обязательным приложением должен быть детально проработанный Устав проекта. В ряде случаев поставщики ИТ-услуг предлагают включать его в состав оплачиваемого подготовительного этапа работ, однако лучше включить Устав в виде приложения к договору и прописать в нем механизмы 22 и инструменты мониторинга и контроля исполнения договорных обязательств. Подробнее о заключении контракта в Приложении 7. Мониторинг и контроль исполнения договорных обязательств, и управление изменениями Собственно, порядок и инструменты мониторинга и контроля исполнения договорных обязательств и управления изменениями (новыми требованиями) имеют значение в основном для поставщиков типа 2. Порядок и инструменты мониторинга и контроля должны быть определены в приложениях к договору, а для проектов – в Уставе проекта. Нет необходимости создавать регламент мониторинга исполнения по каждому договору, достаточно прописать ограниченный перечень регулярно проверяемых пунктов, общих для всех договоров. Поскольку мало какой проект или выполнение работ по договорам долгосрочных поставок обходятся без изменений, лучше иметь прописанный регламент внесения изменений и простой реестр запросов на изменения. Приемка и закрытие работ по договору Формальными документами, обосновывающими завершение работ по договору в полном объёме, является акт сдачи приёмки работ, формат, которого является обязательным приложением к договору, а также товарнотранспортная накладная, являющаяся обоснованием для передачи ПО/оборудования/ материалов. Подписывая Акт приёмки сдачи работ, заказчик своей подписью подтверждает, что работы были выполнены в полном объёме и соответствуют техническому заданию. С момента подписания Акта приема-передачи ИТ-директора все риски утраты или повреждения оборудования, некорректной работы настроенной информационной системы и т.д. переходят к компании. 23 И, как правило, этап до подписания акта – это последняя возможность для ИТ-директора решить большую часть открытых вопросов и воздействовать на поставщика для обеспечения необходимого качества работ по договору, либо поставляемого оборудования/материалов (на основании статей 475 и 518 ГК РФ), решить разногласия в случае поставки некомплектного товара (на основании требований, предусмотренных статьей 480 и 519 ГК РФ.) Бывают ситуации, когда поставщик просит CIO подписать Акт приёмки сдачи работ вместе с Гарантийным письмом поставщика о том, что последний довыполнит оставшиеся работы или до поставит оборудование. В случае, если CIO подписывает Акт, ответственность полностью ложится на него. Обработка платежей Обработка платежей, как правило, является последним этапом сквозной процедуры «от закупки до оплаты», однако зачастую она становится болезненным местом во взаимоотношениях с ИТ поставщиком. Связано это с тем, что практика российского бизнеса, допускающая час точную оплату за еще невыполненные работы, вносит свои коррективы в стандарты, применяющиеся во многих развитых странах. Обилие схем промежуточных оплат также вносит свои коррективы в, казалось бы, простую процедуру. Когда перечень поставщиков и разнообразие договоров начинает исчисляться десятками, ИТ-директору не обойтись без реестра договоров, счетов и платежей, а также без регламента по работе с договорами и счетами для сотрудника, отвечающего за эту работу. 24 Дополнительные материалы 1 https://www.youtube.com/watch?v=ufYTNDFkzT0 Алексеем Лобачевым (ИТ-директор НПФ - Интервью с «Благосостояние» об ощущениях недавно назначенного CIO.) 2 ИТ директор CIO полные обязанности 3 Как выбрать поставщика ИТ-услуг? 25