Краткое резюме
Первый ход Time Platform - задачи из коммуникации
Time уже стал рабочим центром Т-Банка: 50 000 сотрудников, более 2000 ботов и шаблонов процессов, которые команды собрали сами. Спрос на автоматизацию действий внутри Time уже проявлен явочным порядком - следующий шаг в том, чтобы формализовать и укрепить то, что уже работает.
Для команд Т-Банка и Т-Технологий, которые уже живут в Time, Time Platform - единственное решение, где рабочее действие рождается прямо там, где уже идет разговор, а не в отдельном приложении, куда нужно вручную переносить контекст.
Рекомендация
Позиция
Time лучше развивать через один внутренний сценарий. Сначала нужно доказать ценность внутри Т-Банка / Т-Технологий, зафиксировать эффект и затем расширять продуктовую линейку. Продуктовая гипотеза первого продукта: слой задач и договоренностей из Time.
Сообщение в Time превращается в действие с владельцем, сроком, контекстом и статусом. Дальше статус возвращается в канал, а при необходимости задача синхронизируется с TASKS, Kaiten, Yandex Tracker, CRM, ERP, договорной системой или службой заявок.
Финальная рекомендация возможна только после входных условий: внутренний заказчик, пилотные команды, исходный замер, доступ к данным, владелец безопасности и понятная главная система учета.
Почему не вся линейка сразу
По каждому модулю пока нет подтвержденной гипотезы, выделенной команды и владельца результата. Поэтому стратегия "почта, задачи, вики, документы и доски сразу" требует поэтапного сужения до первого проверяемого сценария. Нужна последовательность:
- Выбрать один рабочий сценарий.
- Доказать пользу на внутренних командах.
- Решить, продолжать, менять направление или останавливать.
- После этого расширять модульность по данным.
Почему задачи как первая гипотеза
Задачи из коммуникации сильнее остальных направлений по четырем причинам:
- пользователь видит пользу быстро;
- сценарий естественно встраивается в Time через API, ботов, команды и интерактивные сообщения;
- риск ниже, чем у почтового модуля или умного слоя знаний;
- тот же слой действий может стать общей основой для будущих модулей, если подтвердится боль у юристов, бухгалтерии, продаж, HR, ИТ и продуктовых команд.
Почтовый модуль остается запасным вариантом, если внутренний заказчик подтвердит, что Outlook является болью номер один, и даст безопасный тестовый контур. Умный слой знаний остается стратегически важным: для самостоятельного запуска нужны согласованные правила доступа, аудит, хранение данных, удаление производных данных и разрешенный контур модели.
Модульная модель по ролям
Модульность по ролям стоит рассматривать как гипотезу развития из брифа. Ее надо проверять по ролям сотрудников и их главным системам учета:
| Слой сотрудников | Что им важно | Главная система | Роль Time |
|---|---|---|---|
| Юристы | Договоры, согласования, сроки, риски | Договорная система или ЭДО | Захват поручений из обсуждения и возврат статуса |
| Бухгалтерия и финансы | Счета, акты, платежи, закрытие периода | ERP или учетная система | Уточнения, напоминания и связь с перепиской |
| Продажи | Сделки, следующие шаги, клиентские действия | CRM | Задача менеджеру из переписки и контроль следующего действия |
| HR | Соискатели, офферы, адаптация | HR-система | Координация действий вокруг соискателя или сотрудника |
| ИТ | Инциденты, доступы, сервисные заявки | Служба заявок | Быстрое создание заявки из канала и возврат статуса |
| Продукт и разработка | Решения, задачи, релизы | Трекер задач | Связь решения в канале с задачей и контекстом |
Сильная роль Time: рабочая поверхность вокруг коммуникации, контекста, действия и уведомления. Главные доменные объекты остаются в профильных системах.
Полная линейка модулей шире: помимо слоя задач сюда входят документы, доски, облачное хранилище, аналитика эффективности и умный слой знаний. Каждый модуль входит в карту развития с горизонтом запуска, но попадает в первую версию только при отдельном владельце, данных, бюджете и допуске безопасности. Подробное описание всех модулей - в полной версии стратегии, раздел 8.
Итоговый ориентир после технических штрафов. Задачи лидируют как продуктовая гипотеза.
Условия запуска
Нужны внутренний заказчик, 1-2 пилотные команды, исходный замер, доступ к данным, владелец ИБ и техническая проверка Time API.
Условия запуска и остановки
Запуск пилота возможен только при выполнении шести условий:
- есть внутренний заказчик;
- есть 1-2 пилотные команды;
- есть исходный замер текущего процесса;
- согласован безопасный набор данных;
- назначен владелец безопасности и данных;
- понятно, где хранится главный статус объекта.
Остановить гипотезу надо, если:
- ценность не измеряется за 4-6 недель;
- первая версия требует полной замены зрелой системы;
- нет владельца доступа и данных;
- пилот не меняет поведение пользователей;
- выгода держится на знакомом прошлом опыте без реальной боли внутри компании.
Рамка решения
Сильная позиция стратегии: выбрать первый ход, назвать риски, поставить входные условия, собрать пилот, доказать или остановить гипотезу и только после этого просить команду.