Выбор партнёра, бюджет и тендеры
Стоимость внедрения Salesforce складывается из семи совершенно различных по своей природе компонентов — от лицензирования до интеграций и скрытых внутренних затрат. Тот, кто утверждает бюджет, ориентируясь лишь на одну цифру, обычно сталкивается с перерасходом уже на втором этапе.
Выбор партнёра, бюджет и тендеры
Выбор компании для внедрения Salesforce часто колеблется между двумя крайностями: впечатляющая демонстрация или исключительно сравнение цен. Правильный процесс выбора включает глубокую оценку профессионализма, проверку реальных рекомендаций и анализ модели сотрудничества — прежде чем смотреть на цифру в конце предложения.
Внедрение Salesforce
Средний проект Salesforce длится от шести недель до девяти месяцев, но диапазон дат в предложении почти никогда не зависит от объема разработки — он определяется скоростью принятия решений, готовностью данных и доступностью специалистов в организации.
Внедрение Salesforce
При более чем 500 пользователях вопрос уже не в том, «как строить», а в том, кто принимает решения, кто утверждает изменения и как координировать параллельные инициативы. В статье представлена модель управления, выбор между Single-org и Multi-org, а также типичные сценарии сбоев.
Внедрение Salesforce
Переход между CRM-системами часто терпит неудачу не из-за Salesforce, а из-за непроверенной миграции исторических данных. В статье подробно описано, как сопоставить существующие процессы, выбрать, что оставить позади, и безопасно отключить старую систему.
Архитектура и интеграции
При любой интеграции Salesforce с ERP-системой наступает момент, когда два числа – например, остаток на складе, дебиторская задолженность или статус заказа – противоречат друг другу, и кто-то должен решать, какое из них верное. В данном руководстве мы рассматриваем принятие решений исходя из источника истины, паттерна синхронизации и планирования отказов, а не просто перечня API-соединений.
Данные, миграция и качество данных
Большинство сбоев миграции обусловлены не инструментом, а неправильным порядком загрузки, поспешным сопоставлением полей и отсутствием сверки. Данное руководство описывает полный процесс: профилирование, очистку, использование внешних идентификаторов (External IDs), тестовые прогоны (Dry Run) и исправления после запуска системы (Go Live).
Agentforce и ИИ
Не каждый процесс заслуживает независимого AI-агента. Данное руководство предлагает операционную основу для принятия решений – зрелость данных, обоснование, разрешения и Human-in-the-loop – которая позволяет отличить целесообразные для Agentforce сценарии использования от тех, которые лучше оставить для классической автоматизации.
Выбор партнёра, бюджет и тендеры
Большинство предложений по Salesforce на бумаге выглядят похожими, пока их не проверишь с помощью 15 целенаправленных вопросов. Руководство разбивает их на шесть тем — от команды до преемственности — и показывает разницу между слабым и надёжным ответом.
Оптимизация и спасение проектов
Застрявший проект Salesforce часто кажется результатом ошибок в разработке, но в большинстве случаев это комплексная проблема, включающая неясность функциональных требований, отсутствие архитектурных решений и утрату доверия. Данное руководство предлагает 10-дневный план диагностики и 90-дневную стратегию спасения.
Внедрение Salesforce
Разница между MVP и частично построенной системой заключается не в количестве функций, а в том, какие решения были приняты. Правильная первая фаза полностью закрывает модель данных и разрешения, ограничивая объем бизнес-процессов. В статье представлен четкий тест для определения границ MVP и таблица решений, которые можно и нельзя откладывать.
Внедрение Salesforce
Две ключевые роли, определяющие своевременность реализации проекта Salesforce, почти всегда находятся на стороне клиента, а не поставщика. Здесь мы определяем девять необходимых ролей, их критическое значение, какие позиции нельзя аутсорсить, а также как выглядит матрица RACI, предотвращающая задержки в принятии решений.
Внедрение Salesforce
UAT, который выглядит как экскурсия по экранам, не выявит критичные ошибки, способные сорвать запуск. Тестирование должно охватывать полноценные сценарии, использовать данные, максимально приближенные к реальным, и проводиться конечными пользователями. Данное руководство предлагает методологию построения сценариев, модель категоризации дефектов и чёткие критерии готовности к развёртыванию.
Выбор партнёра, бюджет и тендеры
Выбор модели ценообразования, в первую очередь, определяет, кто несет риск неопределенности. Фиксированная цена не всегда дешевле, а T&M не всегда рискованнее. Каждая модель подходит для определенного уровня зрелости определения объема работ. Здесь вы найдете карту соответствия, защитные механизмы для каждой модели и работающие гибридные подходы.
Архитектура и интеграции
Выбор между Flow и Apex зависит не от навыков команды, а от характера логики: количества записей в транзакции, зависимости от Governor Limits, необходимости Transaction Control и сложности условий. В статье представлен операционный тест для принятия решений, а не очередное общее сравнение возможностей.
Архитектура и интеграции
Выбор неверного шаблона интеграции не проявляется во время демонстрации — это становится очевидным при увеличении нагрузки, минутном сбое внешней системы или одновременном обновлении одного и того же клиента двумя пользователями. Данное руководство представляет основу для принятия решений на основе всего трех вопросов: насколько быстро требуется получать информацию, кто является владельцем истины и что происходит при сбое.
Архитектура и интеграции
Большинство организаций строят модель разрешений сверху вниз: сначала широкий профиль, затем точечные корректировки, пока никто уже не помнит, почему у пользователя есть тот или иной доступ. Правильный подход противоположен: ограниченный профиль для базового доступа и группы наборов разрешений (Permission Set Groups), которые формируют рабочие возможности в соответствии с ролью. В статье это представлено как операционная методология.
Архитектура и интеграции
Решение о переходе на Multi-Org редко принимается одномоментно. Оно чаще всего является результатом накопления уникальных требований бизнес-единиц, регуляторных норм и моделей данных, которые сложно уместить в едином пространстве. В статье представлен тест из трех вопросов для оценки истинной необходимости, экономически эффективная сравнительная матрица и пошаговый план действий для тех, кто уже находится на пути к разделению.
Данные, миграция и качество данных
Большинство сбоев при миграции в Salesforce обусловлены не инструментальными проблемами, а смысловыми: когда одно и то же название поля в двух системах описывает разные сущности. Данное руководство демонстрирует, как создать документ маппинга, который фиксирует бизнес-значение, правила трансформации, значения по умолчанию и ответственности – еще до первой загрузки данных.
Данные, миграция и качество данных
Дублирование — это не проблема данных, а проблема идентификации: организация не определила, что делает две записи одним и тем же клиентом. В данном руководстве показано, как настроить правила сопоставления, построить «золотую запись» (Golden Record), решить, что удалить, а что сохранить в истории, а также как предотвратить повторное появление дубликатов через две недели после загрузки.
Данные, миграция и качество данных
Когда нет четкого определения, кто уполномочен изменять данные, каждая интеграция превращается в переговоры, и в итоге две системы перезаписывают данные друг друга. Данное руководство показывает, как определить единый источник истины для каждой сущности на уровне поля, как отличить систему-отображение от уполномоченной системы и как обеспечить соблюдение данного решения на уровне кода, а не только документации.
Данные, миграция и качество данных
Качество данных становится управляемым только тогда, когда оно имеет числовое выражение, пороговое значение и ответственного. Данное руководство объясняет, какие параметры действительно стоит измерять в Salesforce, как установить непроизвольные пороговые значения, как связать каждую метрику с бизнес-эффектом и как создать информативную систему показателей (Scorecard), к которой будут обращаться чаще одного раза.
Agentforce и ИИ
Не каждое обращение подходит для ИИ-агента, и порядок внедрения определяет успех или провал проекта. Данное руководство ранжирует распространенные сценарии обслуживания по степени зрелости, объясняет требования к каждому из них и показывает, какие сценарии могут показаться привлекательными, но на самом деле подрывают доверие на ранней стадии.
Agentforce и ИИ
Агент не придумывает ответы из злого умысла — он придумывает их, когда источник информации неполон, противоречив или несанкционирован. Данное руководство разбирает Grounding на составляющие: какие источники подключать, как фрагментировать и маркировать контент, как сохранять разрешения при извлечении, и как измерять точность, прежде чем агент начнет взаимодействовать с клиентом.
Agentforce и ИИ
Человеческое подтверждение каждого действия сводит на нет ценность; отсутствие подтверждения любого действия создает риск. Руководство предлагает метод определения точек остановки на основе обратимости, воздействия и чувствительности, описывает три различных шаблона подтверждения и измеряемые условия для снятия точки подтверждения без потери контроля.
Sales Cloud и Service Cloud
Внедрение Sales Cloud часто терпит неудачу не из-за неверных настроек, а из-за этапов продаж, между которыми никто не может точно определить переходы. Это руководство показывает, как построить единую цепочку — Лид, Возможность, Прогноз — где для каждого этапа есть измеримый критерий выхода, и почему это является условием для создания надежного прогноза.
Sales Cloud и Service Cloud
Многие контакт-центры внедряют Service Cloud, но не замечают улучшения времени ответа. Причина почти всегда кроется не в самом инструменте, а в нерешенности четырёх ключевых вопросов: что считать обращением, кто его обрабатывает, с какого момента отсчитывается время ответа и что делать, если ответ уже существует в базе. Это руководство подробно разбирает каждый из этих вопросов, предлагая конкретные решения.
Sales Cloud и Service Cloud
Вопрос о том, какое облачное решение приобрести, часто подается как сравнение продуктов, но на самом деле это вопрос об организации рабочих процессов: управляете ли вы сделками с четким прогрессом или запросами, требующими быстрого реагирования. Это руководство разграничивает Sales Cloud и Service Cloud по объектам, метрикам и лицензированию, демонстрируя, когда необходимы оба решения и как интегрировать их без дублирования данных.
Пользовательская адаптация и управление изменениями
Управление изменениями — это не просто неделя обучения перед запуском. Представляем четырехэтапный план действий: анализ воздействия, привлечение заинтересованных сторон, коммуникации и управленческий цикл, включающий конкретные результаты, ответственных лиц и метрики для каждого этапа.
Пользовательская адаптация и управление изменениями
Обучение, фокусирующееся на интерфейсе, забывается через неделю. Представляем структуру программы обучения, основанной на сценариях: индивидуальный подход для каждой роли, практика на реальных данных в «песочнице», тесты на самостоятельность и непрерывное обучение для новых сотрудников.
Пользовательская адаптация и управление изменениями
Логин — это показатель присутствия, а не ценности. Практическое руководство по созданию набора показателей использования, который измеряет ключевые действия, качество данных и бизнес-результаты, включая базовые показатели, сегментацию по ролям и план действий для каждого вывода.
Оптимизация и спасение проектов
CRM-система почти всегда выходит из строя не сразу. Она изнашивается постепенно, и те, кто ежедневно работает с ней, перестают замечать проблемы. Восемь признаков, приведенных здесь, можно измерить без опросов и консультантов, и каждый из них указывает на первопричину: процесс, данные, архитектуру или управление.
Внедрение Salesforce
Путь изменений от разработки до Production определяет уверенность и безопасность выпуска обновлений. В этом руководстве мы подробно описываем типы Sandboxes, необходимые на каждом этапе, как построить Source-Driven пайплайн с Git и CI, а также что делать с ручной настройкой конфигурации в Production.
Внедрение Salesforce
Hypercare – это не продолжение проекта, а стратегический мост к операционной деятельности (BAU). Структура периода стабилизации: состав команды, временные SLA, ежедневный триаж, измеримые критерии выхода и упорядоченная передача владения внутренней команде.
Внедрение Salesforce
Backlog проекта Salesforce почти всегда терпит неудачу по одной и той же причине: истории описывают экраны вместо результатов, а критерии приемки пишутся уже после разработки. В этом руководстве представлены тестируемая структура истории, метод декомпозиции с использованием Vertical Slice и приоритезация, которая сохраняет актуальность даже при возрастающем давлении.
Внедрение Salesforce
Разрастание объема работ (Scope Creep) возникает не из-за чрезмерного количества запросов, а из-за отсутствия механизма их своевременной оценки. Это руководство предлагает замороженную базовую линию, краткую форму запроса на изменение, еженедельный совет по изменениям и заранее выделенный бюджет на изменения — все это позволяет говорить «да», не рискуя сроками.
Внедрение Salesforce
Дискуссии о методологии в проекте Salesforce на самом деле почти всегда скрывают другие причины: сколько решений можно отложить и сколько времени действительно доступно для пользователей. В этом руководстве выбор модели реализации проекта анализируется на основе трех ключевых переменных, а также описывается гибридная модель, которую фактически применяет большинство организаций.
Внедрение Salesforce
Выбор определяется зависимостью данных и процессов, а не предпочтениями методологии. Структура выбора между единовременным запуском и поэтапным внедрением — включая стоимость сосуществования (Coexistence), риски миграции и таблицу решений по типу организации.
Внедрение Salesforce
Большинство расчетов ROI для CRM-проектов составляются единожды, для презентации утверждения бюджета, и к ним никто не возвращается. Наше руководство предлагает иной подход: четыре типа ценности, измеряемые по-разному, базовые показатели, устанавливаемые до запуска, и правило атрибуции, исключающее приписывание системе всех бизнес-улучшений.
Выбор партнёра, бюджет и тендеры
Запрос предложений, содержащий лишь список требований, породит лишь список обещаний. Хорошо составленный документ, напротив, описывает процессы, объемы работ и открытые вопросы, заставляя каждого поставщика продемонстрировать свой образ мышления. Мы предлагаем девятичастную структуру документа, вопросы, которые помогают выделить лучших поставщиков, и перечень результатов, которые следует требовать от любого предложения.
Выбор партнёра, бюджет и тендеры
Предложение, которое на 30% дешевле, почти всегда является ДРУГИМ предложением, а не ЛУЧШИМ. Правильное сравнение начинается с нормализации: одинаковый объем работ, одинаковый гарантийный период, идентичные скрытые компоненты. Здесь — метод нормализации из шести шагов, карта скрытых затрат, не указанных в предложении, и модель сравнения трехлетней стоимости владения (TCO).
Выбор партнёра, бюджет и тендеры
Большинство разногласий в проектах Salesforce возникают не из-за цены, а из-за вопроса о том, что считать завершенным. Качественный SOW определяет критерии приемки, двусторонние зависимости, права собственности на результаты и порядок расторжения. Ниже представлены двенадцать ключевых пунктов с рекомендованными формулировками и пояснениями относительно их практического значения.
Выбор партнёра, бюджет и тендеры
Комиссия по выбору без согласованной модели оценки почти всегда приходит к решению, которое обосновывается постфактум. Заранее определенная система оценки устанавливает, что измеряется, какие доказательства требуются для каждой оценки и что немедленно дисквалифицирует. Здесь представлена семимерная модель с примерами весовых коэффициентов и процессом оценки, предотвращающим необъективность.
Архитектура и интеграции
Salesforce отслеживает вызовы API в 24-часовых окнах и при превышении пороговых значений блокирует доступ, а не замедляет его. Организациям, одновременно выполняющим ночную синхронизацию, входящие вебхуки и отчеты, необходим тщательно спланированный бюджет вызовов, а не просто повторные попытки после исчерпания квоты. Данное руководство подробно рассматривает практические ограничения: как измерять потребление, когда переходить на Bulk API и как создать механизм экспоненциальной задержки (Backoff), который не перегружает систему второй волной сбоев.
Архитектура и интеграции
Platform Events и CDC решают одну и ту же проблему: разобщение между системами, которым не нужно ждать друг друга. Проблема возникает, когда выбор между ними делается исходя из технического удобства, а не из того, кому принадлежат данные, требуемого уровня надежности, и что происходит, когда сообщение приходит дважды или не приходит вовсе.
Архитектура и интеграции
SAML или OIDC, инициация IdP или SP, JIT или SCIM для управления жизненным циклом — каждый выбор в архитектуре Identity для Salesforce определяет, кто получает доступ к системе, с какими разрешениями и что происходит в день увольнения. Статья представляет конкретную систему принятия решений, включая сценарий неудачного оффбординга и способы его исправления.
Архитектура и интеграции
Открытые OWD, установленные «чтобы никого не блокировать», и иерархия ролей, развивающаяся спонтанно, прокладывают кратчайший путь к отчетам, где региональный менеджер видит всех клиентов своего внутреннего конкурента. Данная статья предлагает обратный подход: сначала мы определяем, кто, что и почему должен видеть, и только затем выбираем между OWD, Role Hierarchy, Sharing Rules, Teams и Apex Sharing.
Архитектура и интеграции
Большинство сбоев интеграции, с которыми сталкиваются клиенты, вызваны не отказом API, а незаметным сбоем сообщения, который никто не заметил. В статье рассматриваются четыре уровня обработки ошибок: идемпотентность, повторные попытки (Retry), очереди недоставленных сообщений (Dead Letter) и сверка (Reconciliation). Мы покажем, где каждый из них дает сбой на практике.
Архитектура и интеграции
Технический долг в автоматизации Salesforce возникает не из-за ошибочного выбора между Flow и Apex, а сотнями мелких решений, принятых без общей стратегии и долгосрочного видения. В статье показано, как выявить его на практике — используя данные, а не интуицию — и как построить план сокращения, который не замедлит темпы разработки.
Данные, миграция и качество данных
Модель данных — это решение, требующее наибольших затрат на изменение после запуска. В руководстве рассматриваются вопросы: когда использовать стандартные объекты, когда оправдан индивидуальный объект, как выбрать между отношением поиска (Lookup) и отношением «главный-подчинённый» (Master-Detail), и как модель, выглядящая чистой на этапе проектирования, впоследствии приводит к ограничениям в отчётности, разрешениях и производительности.
Данные, миграция и качество данных
MDM терпит неудачу, когда рассматривается как технологический проект, и преуспевает, когда определяется как режим управления. Руководство объясняет, какие сущности действительно требуют Master-управления, как создать Golden Record между CRM и ERP без ущерба для систем, когда необходим специализированный инструмент MDM, а когда Salesforce достаточно, а также как измерить эффективность режима.
Данные, миграция и качество данных
Не все данные, связанные с клиентами, должны храниться в CRM. Наше руководство разграничивает операционные данные, управляющие повседневными процессами, и высокообъемные поведенческие данные, предназначенные для объединения профилей, сегментации и активации. Мы покажем, как это решение влияет на производительность, стоимость, разрешения и возможности использования AI.
Данные, миграция и качество данных
Каждое копирование данных влечет за собой обязательства: инфраструктура, затраты, расхождения и риски. Zero Copy позволяет запрашивать данные там, где они находятся, но это не универсальное решение. В данном руководстве мы рассмотрим, когда предпочтителен виртуальный доступ, когда более уместна ингестация данных, и как принять решение, основываясь на таких факторах, как актуальность, производительность, управление данными и стоимость трафика.
Данные, миграция и качество данных
День перехода к новой системе Salesforce часто завершается неудачей не из-за ошибок загрузки данных, а из-за сопутствующих проблем: необработанных дельта-изменений, преждевременно запущенной интеграции или отсутствия лица, принимающего решения в два часа ночи. Наше руководство предлагает почасовой план Cutover, правила заморозки данных (Freeze), четырехуровневый метод сверки (Reconciliation) и четкие критерии Go/No-Go.
Agentforce и ИИ
Стоимость лицензирования легко рассчитать, но часто она не является основной статьей расходов. Данное руководство делит общую стоимость владения (TCO) на пять компонентов — лицензирование, потребление, разработка, эксплуатация и поддержка контента — и предлагает формулу расчета затрат на задачу. Это позволяет сравнивать стоимость агента с затратами на обслуживание, управляемое человеком, вместо того чтобы полагаться на обещания.
Agentforce и ИИ
Платформа обеспечивает безопасность инфраструктуры; организация отвечает за то, что агент имеет право видеть и делать. Данное руководство описывает фактическую линию разграничения — данные, разрешения, инструкции, действия и мониторинг — и показывает, какие новые риски возникают с агентом, не имеющим аналогов в обычной системе CRM.
Agentforce и ИИ
Тестирование агента отличается от тестирования Flow: один и тот же вопрос может иметь несколько корректных ответов. В этом руководстве мы покажем, как создать тестовый набор, максимально точно имитирующий реальные условия, какие параметры следует измерять отдельно, когда автоматизация достаточна, а когда требуется вмешательство человека, и какой порог позволяет выпустить продукт в эксплуатацию.
Agentforce и ИИ
Агент без мониторинга - это чёрный ящик, который никто не сможет защитить на совещании с руководством. В нашем руководстве слой мониторинга разделён на три уровня: одиночный диалог, тренды и бизнес-результат. Мы объясним, что обязательно должно отображаться в трассировке, и как превратить неудачные диалоги в еженедельный рабочий процесс вместо отчёта, который никто не читает.
Agentforce и ИИ
Для каждого действия, выполняемого агентом, существует четыре способа реализации, и различия между ними не только технические: они касаются того, кто будет поддерживать, как тестировать и сколько времени займет внесение изменений. Это руководство предлагает четкий порядок выбора, стоимость обслуживания каждого варианта и случаи, когда Apex является правильным выбором, несмотря на затраты.
Agentforce и ИИ
База знаний, созданная для людей, не подходит для ИИ-агентов: она содержит противоречивые версии, документы без владельцев и смешанный внутренний и клиентский контент. Данное руководство представляет пятиступенчатый процесс подготовки — аудит, архивация, структурирование, тегирование и назначение владельцев — с пороговыми значениями индексации и долгосрочной моделью поддержки.
Agentforce и ИИ
Неэффективное управление ИИ проявляется двумя крайностями: либо комитет блокирует все инициативы, либо отсутствие контроля обнаруживается только во время аудита. Данное руководство представляет многоуровневую модель рисков: кто что утверждает, какие обязательные меры контроля необходимы на каждом уровне, какие документы действительно требуются и как поддерживать скорость, не жертвуя ответственностью.
Sales Cloud и Service Cloud
Процесс Lead-to-Cash практически всегда характеризуется тремя критическими точками перехода: от лида к сделке, от сделки к утвержденному коммерческому предложению и от предложения к заказу в ERP. Данное руководство описывает обязательные конфигурации для каждой из этих точек, объясняет, как принять решение о месте хранения ценовой информации, и почему утверждение скидок часто становится реальным узким местом.
Sales Cloud и Service Cloud
Если менеджер по продажам ведет прогноз в отдельной таблице, проблема не в дашборде. Надежный прогноз базируется на четырех предварительных условиях: корректная иерархия, чистые даты закрытия, согласованные категории и регулярный цикл обзора. Это руководство объясняет, как их выстроить, и что измерять для оценки реального улучшения прогноза.
Sales Cloud и Service Cloud
Omni-Channel часто не справляется со своими задачами не из-за настроек маршрутизации, а из-за модели пропускной способности: когда чат, электронные письма и телефонные звонки оцениваются по одной и той же единице измерения, операторы либо перегружены, либо простаивают. В этом руководстве объясняется, как задать весовые коэффициенты для расчёта нагрузки, связать права (Entitlements) с маршрутизацией, а также как заблаговременно определить, что модель не выдерживает нагрузку.
Sales Cloud и Service Cloud
Базы знаний обычно выходят из строя не при запуске, а на второй год: статьи написаны единожды, никто их не поддерживает, и сотрудники возвращаются к внутренним чатам. Это руководство описывает жизненный цикл, который обеспечивает долгосрочную работу — стоимость, триггер для создания, периодический пересмотр и измерение использования — и что меняется, когда ИИ-агент обращается к той же базе.
Sales Cloud и Service Cloud
Скорость интеграции телефонии с Salesforce измеряется секундами: сколько времени проходит, прежде чем оператор увидит, кто звонит и по какому вопросу. Это руководство рассматривает ключевые решения, определяющие результат: идентификацию абонента, Screen Pop, управление маршрутизацией, обработку переводов и разъединений, а также выбор между Service Cloud Voice и существующим CTI-адаптером.
Пользовательская адаптация и управление изменениями
Чемпион — это больше, чем просто формальный титул. Мы расскажем, как выбрать представителей на местах, сколько времени им выделить, что именно включает в себя их роль, как мотивировать и как предотвратить затухание сети через два месяца.
Пользовательская адаптация и управление изменениями
Каждое лишнее поле — это ежедневный налог на каждого пользователя. Представляем практический подход к оптимизации экранных форм в Salesforce: анализ использования полей, тест трех кликов, оптимизация макетов по ролям и измерение времени выполнения задач до и после изменений.
Пользовательская адаптация и управление изменениями
Неудачный запуск — это не проблема обучения. Практическое руководство по восстановлению: как диагностировать причину оттока, что исправить в первые 30 дней, как восстановить доверие без объявления о «перезапуске» — и когда лучше сократить систему, а не расширять её.
Оптимизация и спасение проектов
Решение между точечным ремонтом, рефакторингом и полной перестройкой зачастую принимается интуитивно, поэтому проблемы возвращаются уже через два года. Данное руководство представляет четыре объективных критерия оценки, объясняет, почему "перестройка с нуля" почти всегда обходится дороже предварительных оценок, и описывает практический путь поэтапной замены системы.
Оптимизация и спасение проектов
Список технического долга длиной в сотню строк – это не инструмент для работы, а источник разочарований. В нашем руководстве представлена система оценки по четырём измерениям, которая помогает навести порядок, объясняет, какой вид долга необходимо решать в первую очередь независимо от оценки, и как перевести технический долг в язык, понятный для получения бюджета.
Оптимизация и спасение проектов
Замедление работы Salesforce практически никогда не является одной большой проблемой, а представляет собой совокупность факторов: перегруженный интерфейс, неселективные запросы и дублирующиеся автоматизации. Данное руководство предлагает послойный метод диагностики — браузер, интерфейс, сервер, данные, интеграция — и метрики, позволяющие доказать улучшение производительности.
Внедрение Salesforce
Большинство неудач при внедрении Salesforce связаны не с разработкой, а с этапами перехода: поспешный переход от Discovery к реализации, миграция без тщательной проверки и UAT без ответственного владельца. Данное руководство подробно описывает процесс внедрения по этапам, deliverables и процедурам утверждения.
Архитектура и интеграции
Организация, добавляющая Custom Objects, Flows и точечные интеграции без документированного архитектурного уровня, накапливает технический долг, который проявляется при попытке добавить новый бизнес или выйти на новый рынок. Эта статья анализирует архитектуру Salesforce, разделяя ее на шесть практических уровней.
Внедрение Salesforce
Discovery, завершающийся красиво оформленной презентацией, — это не Discovery. По окончании этапа проектирования на столе должны лежать семь ключевых результатов, на основе которых можно строить, оценивать стоимость и проводить тестирование. Данное руководство подробно описывает содержание каждого результата, критерии его зрелости и адекватные временные затраты.
Внедрение Salesforce
Большинство неудач в проектах CRM обусловлены не техническими сбоями, а отложенными решениями. В этом материале мы рассмотрим десять типичных ошибок, которые встречаются в проектах Salesforce, расскажем о ранних признаках их появления и о превентивных мерах, которые позволят минимизировать затраты при их своевременном применении, и избежать значительно больших расходов после запуска системы.
Выбор партнёра, бюджет и тендеры
Большинство компаний обращаются к поставщикам с запросом на «внедрение», даже когда их истинная потребность заключается в диагностике или сопровождении. Неправильный выбор типа услуги часто приводит к проектам, результаты которых не соответствуют ожиданиям. Мы предлагаем классификацию услуг в зависимости от симптомов: что заказывать в каждой ситуации, какой результат ожидать и на какие тревожные сигналы обращать внимание.
Выбор партнёра, бюджет и тендеры
Консультант Salesforce нужен в тех случаях, когда ошибка может дорого обойтись – и далеко не по каждому техническому вопросу. В этой статье мы определяем пять "триггеров", оправдывающих привлечение внешнего консультанта, объясняем разницу между консультантом, архитектором и администратором, а также подробно описываем результаты, без которых вы просто потратите деньги на встречи, а не на решения.
Agentforce и ИИ
Прежде чем создавать первого агента, стоит ответить на более простой вопрос: насколько организация готова к этому. Данное руководство представляет проверку готовности по пяти ключевым направлениям — процесс, данные, знания, полномочия и эксплуатация — с оценкой для каждого направления, минимальным порогом для пилотного проекта и рекомендациями по устранению выявленных пробелов.
Оптимизация и спасение проектов
Health Check – это не опрос общественного мнения о системе, а диагностика, основанная на фактах: метаданных, логах, данных об использовании и наблюдении за реальными пользователями. Руководство подробно описывает семь направлений проверки, методологию оценки критичности и структуру конечного отчета, на основе которого можно принимать бюджетные решения.