Некоторые мысли по развитию ит-сектора

Compliance и Контрагенты

Карта рисков для информационных систем «Что будет, если упадет вот этот квадратик и пролежит день». Все говорят, что все зарезервировано и работает, но на самом деле нет. Потом оказывается, что резервный ЦОД не вывезет нормальную нагрузку при отключении основного ЦОДа. Из десятка организаций, в которых я имел возможность задать этот вопрос за последние 10 лет, только одна смогла положить канал и переключиться, но после полуторагодового проекта по DR. Если нет, то хоть в каком-то виде надо нарисовать, чтобы понять, что где укреплять, и как обрабатывать руками, если все в результате внешнего воздействия или само по себе все упадет. 

Степень лицензирования и даты последних аудитов с результатами. После того как основные лицензиаты нас покинули, вопрос может показаться неактуальным, но нет. Лицензионные претензии, как правило, завышены в 5-20 раз, а M&A сделка прямо прописана как триггер для проверки или для претензии с новыми неразобравшимися менеджерами

Поэтому важно сразу понимать, как много не докуплено, как с этим жили и как вести диалог дальше. 

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

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

АРМы контрагентов (если есть) – это суперважная штука, которая не зависит от тебя, надо понять, как ее охранять и не дать ею манипулировать. Даты замены ключей и ответственные, а также способы хранения паролей давно работающие сотрудники забудут напомнить, а ты прощелкаешь и невольно остановишь операционный процесс.

Долгосрочные обязательства, контракты и договоры длительностью от 1 года. Всегда есть шанс пропустить такой в этом году, потому что платили в позапрошлом году, и внезапно обнаружить у себя круглую сумму на продление поддержки на 3-5 лет в бюджете следующего года.

BCP и DRP с планами перехода и указанием ответственных и акты текущих тестов. В одной американской организации для обновления этой истории и регулярного тестирования был выделен целый человек, и все равно, когда случился пожар (8:30) процедура не помогла к 10 часам быть наготове проводить клиентские операции

Тем не менее, каждому важно понимать свои действия во время DRP. Кому звонить, кого не трогать, и что делать самому

Очень хороший сводный документ на эту тему есть у Microfocus (открывается с VPN), там хорошая не только техническая, но и организационная часть, которой обычно не хватает.

Доступность сервиса — это про бизнес, но и про ИТ

Итак, что же такое доступность сервиса? Я сформулировал для себя следующее определение: Доступность сервиса (англ. Service Availability) — это такое состояние нашего ИТ-окружения, когда наши клиенты могут и хотят получить услугу и остаться в целом удовлетворенными. Стоит также подчеркнуть, что здесь может быть только два состояния: либо условия выполняются, либо нет. Все полутона только смазывают картинку. Никакой деградации, никакой сниженной производительности — все это технические показатели, необходимые исключительно инженерам для оценки динамики состояния системы. 

Приведу пример: потенциальный клиент хочет подать онлайн-заявку на оформление кредита в банке, но система работает со сбоями. Из-за высокого времени ожидания ответа сервера форма постоянно сбрасывается или на ней возникают ошибки, но минут за 30 заявку можно подать. Это приводит к тому, что конверсия в воронке продаж резко падает. С позиции классического инженерного мониторинга это серьезная деградация, но услуга доступна, а вот с позиции бизнеса это неприемлемое состояние системы, когда он теряет потенциальных клиентов. В данном примере доступность сервиса должна считаться равной 0. Приведу обратный пример: у вас, в силу каких-то непредвиденных обстоятельств, полностью выключается целый ЦОД и ваши системы переходят на резервный, при этом клиенты в штатном режиме, правда, чуть дольше, чем обычно, но регистрируют заявки на кредит, и конверсия не падает. А тут мы говорим, что сервис доступен полностью и мы, как инженеры, молодцы — обеспечили горячее резервирование. Хотя при этом половина наших серверов и каналов связи находятся в коме и  “не доступны”. Таким образом, определение доступности сервиса целиком находится на стороне бизнеса, а мы должны лишь зафиксировать в каком соответствующем состоянии должно находится наше ИТ-окружение. Можно поддаться искушению сделать все просто и повесить, например, метрику конверсии как KPI для ИТ-департамента, забывая при этом, что ИТ не про конверсию, его нормальная работа — необходимое, но недостаточное условие для продвижения клиентов по воронке продаж. Поэтому использование бизнес-метрики в лоб приведет к непониманию и отторжению инженерного состава. К сожалению, этому искушению простоты очень часто поддаются руководители и в результате получают прямо противоположный эффект.

Так рынок перегрет?

На самом деле трудоустройство даже 60% недавних выпускников онлайн-курсов — дело вряд ли осуществимое. Особенно — если учитывать тот факт, что работодатели не спешат нанимать новичков, которых нужно обучить до нужного уровня и ещё начислять зарплату всё это время.

«Компания смотрит на джунов через призму инвестиций, так как должна вложить время и ресурсы в его обучение. На собеседовании быстро становится понятно, почему кандидат переучился — искренне интересуется и обладает системными знаниями или пришел только за деньгами. Так и получается, что кандидатов много, а подходящих мало», — сказала Елена Охота, заместитель руководителя отдела управления персоналом компании Axoft.

Общая ситуация такова: вкладываться в обучение новых кадров, особенно в условиях, когда компании не могут прогнозировать своё будущее, готовы только крупные игроки. И то — только в формате стажировок, чтобы вырастить спецов под себя и потом нанять не по конским ценам.

Факторный анализ

Как я отмечал выше, важно не только получить метрику, но и суметь ее декомпозировать — разложить на составляющие, чтобы в итоге понять, какие проблемы стали критическими, а какие — наоборот, внесли меньше всего вклада в сложившуюся ситуацию. Это позволит нам, например, понять, куда стоит вкладывать наш ограниченный бюджет, где самая красная точка. . Факторный анализ позволяет определить: какой фактор-проблема повлиял за отчетный период на расчет доступности и сравнить степень такого влияния с остальным факторами-проблемами

Факторный анализ позволяет определить: какой фактор-проблема повлиял за отчетный период на расчет доступности и сравнить степень такого влияния с остальным факторами-проблемами.

Предположения методики:

• В методике определения доступности невозможно определить вес той или иной проблемы, если они произошли одновременно. Таким образом, единственным параметром будет длительность проблемы.

• В случае, если одновременно произошли две и более проблемы, то на такой период будем считать длительность каждой с коэффициентом 1/N, где N — количество одновременно произошедших проблем.

Методика расчета:

1. Необходимо взять функцию fProblem(t), построенную при расчете SA. 

2. Для каждого участка, где итоговая функция fProblem(t) = 1, составить список проблем данной КЕ, на основании которых данному участку было присвоено значение. При составлении списка необходимо учитывать и проблемы, которые начинались или заканчивались за пределами участка функции.

3. Проставить проблеме метрику влияния. Она равняется длительности проблемы на участке умноженную на вес. В случае, если на участке в области свой длительности проблема была единственная, то ей устанавливается вес, равный 1, в случае множественных проблем  вес равен 1/N, где N — количество одновременно произошедших проблем.

4. При расчете следует учесть следующие моменты:

   1. В общем случае на одном и том же участке на разных интервалах вес проблемы мог меняться  из-за появления новых проблем.

   2. Одна и та же проблема может присутствовать на разных участках fProblem(t) = 1. Например, проблема началась в пятницу, закончилась во вторник, а в выходные КЕ не обслуживается согласно SLA. 

      

      

      

      

      

      

      

      

      

      

5. В итоге должен быть сформирован список проблем, которые участвовали в расчете функции fProblem(t). При этом у каждой проблемы должна быть посчитана метрика влияния на SA.

6. Необходимо обязательно верифицировать расчет. Сумма метрик влияния всех проблем должна равняться timeWorkingProblem. 

7. Пользователю необходимо выводить относительное значение влияния в %. Для этого метрику влияния необходимо разделить на timeWorkingProblem и умножить на 100%.

8. В случае, если нужно группировать проблемы и показывать влияние группы, достаточно суммировать метрики всех входящих в группу проблем. Это утверждение справедливо, только если выполняется следующее условие: каждая проблема может одновременно входить только в одну группу. 

В результате получаем вот такую картину (см. рис 4.)

Рис. 4 Анализ и оценка проблем в расчете доступности

SLA, OLA и UC при предоставлении информационно-технологических услуг

В большинстве случаев стандарты, согласно которым должны оцениваться ожидания, оптимизация и параметры производительности, должны быть полностью перечислены в каталоге оказываемых аутсорсером услуг, регулируемых Соглашением об уровне обслуживания (SLA) и соглашением об уровне операционного обслуживания (OLA). При ИТ аутсорсинге между специализированной организацией и клиентским предприятием заключается внешний договор (UC).

SLA – Service Level Agreement — Соглашение об уровне услуг — является соглашением между аутсорсером и заказчиком, в котором подробно описаны все предоставляемые ИТ сервисы. Особенностью SLA остается то, что все услуги должны быть в нем представлены на уровне понимания клиента, то есть, без технических терминов, которые могут быть ему незнакомы и непонятны. На весь срок, на который оно заключается, Соглашение об уровне сервиса используется в качестве стандарта оценки и при необходимости корректирования оказания ИТ услуг.

Стандартная модель SLA обычно содержит:

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

Соглашение об уровне обслуживания также содержит и спецификацию целевых уровней качества сервиса, в том числе:

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

OLA — Operational Level Agreement — Операционное соглашение об уровне услуг — представляет собой соглашение, заключенное между компанией и ее внутренней ИТ службой. В этом документе необходимо конкретизировать договоренности о предоставлении определенных компонентов ИТ сервисов (включая уровень доступности сети, печати и др.). Если Соглашение об уровне сервиса содержит в себе временные нормы устранения инцидентов на основе уровня их критичности, то OLA определяет задачи участников процесса ИТ поддержки, не забывая и о тех функциях, которые были переданы внешней аутсорсинговой фирме.

UC — Underpinning contract — Внешний договор – является видом договора с аутсорсером, определяющим договоренность оказания определенных услуг. Механизм действия договора схож с реализацией OLA. Так как во многих компаниях информационную инфраструктуру обслуживает внутреннее ИТ подразделение, как OLA, так и SLA являются фактически описаниями параметров, о поддержании которых между собой договорились их подразделения. Договор с аутсорсинговой организацией практически в обязательном порядке составляется и оформляется как правовой официальный документ.

Какие сервисы передают на аутсорсинг

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

Управление ИТ-сервисами

Узнать больше

Администрирование серверов

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

Администрирование виртуальной инфраструктуры

Если инфраструктура клиента размещена в публичном, частном и гибридном облаках, можно отдать её администрирование на аутсорсинг. Другой вариант — управлением занимается та же компания, что предоставляет виртуальную инфраструктуру. Это снижает расходы на поддержку ИТ-инфраструктуры и помогает сосредоточиться на развитии бизнеса. Стартапам и компаниям, которые только начинают создавать ИТ-инфраструктуру, выгодно доверить это сторонним специалистам, чтобы сэкономить на покупке дорогостоящего оборудования и на штатных сотрудниках.

ИТ‑сервисы Microsoft

Сервисы Microsoft могут работать не только на ПК, но и в облаке. Компания может арендовать почтовый сервер, сервис SharePoint, каталоги Active Directory, Windows Server, SQL-сервер, хранилище OneDrive, Skype, Word и Excel. Благодаря этому не придётся тратить ресурсы на покупку, обслуживание и обновление софта.

Managed DevOps

Сторонняя компания может выступать в качестве DevOps-инженера, помогать упорядочить работу над проектом, объединять разработчиков, тестировщиков и продуктологов. ИТ-специалисты с помощью необходимых инструментов, в том числе Docker и Kubernetes, создадут удобную конвейерную среду для разработчиков. Также в список услуг может входить администрирование серверного и сетевого оборудования, ПО и сервисов, быстрое исправление критических ошибок. Это помогает автоматизировать и систематизировать все процессы, от сборки до тестирования и доставки приложений.

Проектирование и обслуживание корпоративных сетей

Проектирование, создание, обслуживание и администрирование сетей требует специализированных знаний. Как правило, компаниям со штатом менее 5000 сотрудников выгоднее передать это на аутсорсинг. Привлечённые специалисты полностью возьмут все задачи на себя и проконтролируют работы по монтажу, прокладке оптического кабеля и т. д. Заказчик не только сэкономит бюджет, но и получит надёжную сеть с высокой пропускной способностью.

Виды ИТ-аутсорсинга

В зависимости от выполняемых задач, аутсорсинг ИТ-сервисов делят на ресурсный, функциональный и стратегический.

• Ресурсный аутсорсинг — это аренда ресурсов, которыми заказчик будет управлять самостоятельно. Можно взять в аренду виртуальные серверы в ЦОДе провайдера или ИТ-специалистов. При этом аутсорсинговая компания не занимается администрированием и не отвечает за уровень сервиса.
• Функциональный аутсорсинг — передача части ИТ-сервисов на внешнее обслуживание. Сюда относится аутсорсинг поддержки серверной инфраструктуры, облачные сервисы класса SaaS и т. д. Компания, которая занимается аутсорсингом, берёт на себя ответственность за уровень сервиса.
• Стратегический аутсорсинг — полное управление ИТ-инфраструктурой. Заказчик полностью передаёт задач по обслуживанию информационной системы. Это помогает компании получить в распоряжение надёжно работающие сервисы и не заниматься вопросами их администрирования, масштабируемости и безопасности.

Революционный подход к ИТ обновленной России

Новые российские разработки должны нацеливаться не только на внутренний рынок, а на мировой. Масштабирование позволит получить больше пользователей, соответственно, обеспечит большую устойчивость разработкам, а также создаст конкуренцию монополистическим западным системам. Соответственно, произойдет перераспределение финансовых потоков от рекламы и прямой монетизации в наши компании. Более того, мы сможем присутствовать в информационном поле множества стран, обеспечивая дополнительную финансовую и политическую устойчивость России.

Мо моему мнению, Россия должна стремиться стать ведущим поставщиком открытого программного обеспечения по всему миру. Напоминаю, открытое не значит неприбыльное, вспомните Red Hat Linux.

Для этого  придется пересмотреть подходы к разработке программного обеспечения, возможно создать новые технологические стандарты мирового уровня. Я нисколько не сомневаюсь в интеллектуальном потенциале наших ребят, главное правильно организовать целеполагание и процесс разработки.

Изменение ИТ ландшафта

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

Сначала подробно анализируем потребности определенного сегмента бизнеса (по отдельности будет проще, потом итоговые выводы сложим). Посмотрим какими инструментами они удовлетворяют свои потребности, как широко их охватывают и насколько эффективно, и насколько комфортно.

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

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

На основании анализа делаем ТЗ общего характера, эдакий запрос государства на ИТ-продукт. Это может быть язык программирования, библиотека, стандарт и т.п. Причем, результат предоставляется не в качестве собственности какой то-конкретной организации, а в виде продукта с открытым исходным кодом. 

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

Естественно, отбирается только часть заявок и предлагается полное или частичное финансирование (разбитое на этапы, привязанное к вехам). Возможно стоит сделать так, чтобы одновременно 2-4 команды независимо друг от друга пытались реализовать проект, так идет страховка от неудачи и появляется возможность выбрать более эффективное решение. 

Развитие базовых госсервисов

Также можно посмотреть какова ситуация с информационными сервисами, которые может предоставлять государство напрямую. Это могут быть данные по контрагентам, геоданные, статистические, т.е. те, которые может использовать малый и средний бизнес напрямую для своих сервисов. Возможно следует улучшить API, их доступность, скорость.

Вот так пробежались по верхушкам. Я здесь намеренно не задаю все вопросы и не даю готовые ответы, т.к. в этом направлении ещё много работы. Вышеизложенное касается в первую очередь “попсовых” направлений ИТ, а ведь есть ещё радиоэлектроника и робототехника, которая, можно сказать, ещё в личиночной стадии развития. К тому же все эти вопросы следует рассматривать в связке с законодательством, судебной системой, налогообложением, внутренней и внешней политикой, анализом ресурсной базы и даже экологией. У нас много думающих людей и они прекрасно понимают, что текущие меры не помогут спасти, а тем более оздоровить сферу ИТ. Необходимо более вдумчиво подходить к реализации инициатив поддержки ИТ отрасли, нежели это происходит сейчас.

Персонал

Расходы на команду в финансовом секторе составляют порядка 60%, поэтому дальше мы формируем блок вопросов про людей.

Доверенности на сотрудников сразу показывают ключевых сотрудников и распределение чувствительного функционала. 

Организационно-штатная структура ИТ – кажется, что это первым делом просят все и всегда, просто как базовый ориентир. 

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

Место сотрудников с ИТ-функцией в общей оргструктуре, но не находящихся в ИТ – то, что Gartner называет shadow IT, поскольку такие люди могут оказаться надежными контрагентами, а могут навтыкать палок в колеса. Поэтому необходимо идти и сразу знакомиться с коллегами, узнавать проблематику с ИТ, договариваться о том, как работать дальше. 

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

Список сотрудников без «бэкапа» функционала на время отпусков – это операционно неустойчивая структура, которую надо сразу же устранять, нельзя перегревать человека и не давать ему отдыхать сутками напролет. Часто оказывается, что эти сотрудники входят в список ключевых (см. предыдущий пункт). 

ФОТ (staff cost), переработки, количество неиспользованных отпускных дней. Ранее я говорил про 60% расходов? Люди с длинным хвостом отпусков (а мы с вами компанию покупаем, и коллеги могут все разом психануть и уволиться) – это потенциальный риск нагрузки на годовой ФОТ, из нашей практики процентов на 7-15%. А переработки в принципе могут создать двойную нагрузку. Еще интересно сравнивать плановый и фактический ФОТ, потому что при планировании все комбинации учесть невозможно, точно так же, как и всех творческих людей одновременно идентифицировать. 

Ответственные за прием оборудования, ответственные за склады

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

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

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

Ответственные за закупки. Ответственные за платежи ИТ и ведение договоров. Надо понять, это лица, принимающие решения, или исполнители и совмещаются ли роли с вендор-менеджерами.

Правила клиентского сервиса

Универсальных правил построения клиентского сервиса нет — в каждой компании они будут своими. Рассказываем на примере Тинькофф.

Подкаст «Бизнес-ланч» про клиентский сервис с Магомедом Гасановым из Тинькофф Бизнеса

Клиент — главный человек в компании. В Тинькофф мы говорим сотрудникам так: если клиент доволен, он приносит больше денег компании. Поэтому мы постоянно занимаемся клиентским сервисом.

Например, клиент подключил расчетный счет на самом простом тарифе. Казалось бы, банк получает мало денег. Но мы относимся к этому клиенту так же, как и к остальным: отвечаем на вопросы в любое время, предлагаем выгодные условия на нужные клиенту продукты.

Клиенту все нравится, в какой-то момент он начинает участвовать в госзакупках. И покупает у нас банковскую гарантию.

Оборот растет, и клиенту нужно переводить больше денег. Он подключает более дорогой тариф. А тут еще и учет становится сложнее — предлагаем ему подключить бухгалтерию.

Так ИП на простом тарифе начинает использовать все больше наших продуктов. А все потому, что ему нравится с нами работать.

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

Наши сотрудники знают, что кормилец компании не менеджер, а клиент: идея постоянного улучшения клиентского опыта всех объединяет.

Относимся к клиентам неравнодушно. Конечно, сотрудники иногда совершают ошибки — это бывает у всех. Это еще не значит, что клиентский сервис плохой. По-настоящему плохим он становится, если относится к клиенту равнодушно.

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

Решение вопроса клиента не должно ломаться на процессе. Мы готовы измениться, если это поможет клиентам быстрее решать их вопросы.

Тинькофф сделал ставку на развитие сервиса: компания совершает ошибки, но признает их и старается исправить. Благодаря этому продуктами экосистемы пользуются больше 12 млн клиентов.

Продукты и сервисы для клиентов

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

Планы развития продуктов и сервисов на текущий год

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

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

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

Список проектов, завершенных за два предыдущих года и список текущих проектов. Сразу становится понятно, какие вещи не делаются, к ним стоит присмотреться внимательнее и закрыть. Также интересны активности, которые проектами не являются, но, представленные в качестве проектов, могут повлечь за собой значительные расходы. Отдельно стоит присмотреться к бюджетам ИТ-проектов: тут интересно понимать, сколько в него включено Business as usual (непроектных) расходов, и делаются ли проекты в принципе.

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

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