Основной задачей данного раздела является подготовка вашей компании к внедрению у себя системы CRM с участием профессиональной
В основе раздела лежит методология внедрения информационных систем компании Sputnik Labs, адаптировавшая опыт крупнейших мировых производителей прикладного программного обеспечения для автоматизации среднего бизнеса (предприятия с количеством сотрудников от 20 до 2000) к условиям российской действительности.
Здесь вы найдете базовую информацию по организации своего проекта внедрения, включая утверждение структуры команды, планирование и отчетность по проекту, план внедрения, а также краткое описание существующей проектной
Отдельный раздел посвящен подготовке вашей проектной команды к непосредственному запуску проекта (т.н. "Project Kick-off"). Этот раздел объясняет важность правильного анализа бизнес-потребностей и их формализации. Здесь же даются рекомендации, как лучше подготовить информацию по бизнес-процессам, чтобы сделать запуск проекта наиболее эффективным.
Мы также включили раздел про обучение для участников вашей команды внедрения, которое будет проходить, начиная с момента запуска проекта, а также в процессе дизайна и внедрения системы, а также после ее окончательного развертывания.
Мы уверены, что, следуя описанным здесь рекомендациям, вы сможете хорошо подготовиться к проекту внедрения системы и извлечь максимальную пользу из вложенных в него ресурсов.
Чтобы не путаться в терминах, мы предлагаем использовать следующие основные определения:
| Заказчик | Компания, внедряющая у себя решение CRM сопривлечением внешних профессиональных консультантов. Данное руководство ориентировано в первую очередь на руководителей проекта внедрения в подобных компаниях |
| Подрядчик | Компания — поставщик профессиональных услуг в области внедрения систем CRM, такая как Sputnik Labs |
Что мы вкладываем в понятие "защита проекта"? Любое начинание в компании сталкивается с противодействием. В нашем случае CRM-проект может столкнуться с большим количеством различных тормозящих факторов: непониманием и невниманием со стороны руководства, апатией или даже саботажем со стороны конечных пользователей, консерватизмом ИТ-специалистов, ограничениями корпоративных стандартов, нежеланием партнеров раскрывать информацию и многими другими.
Далее мы рассмотрим большинство из препятствий, возникающих обычно при внедрении CRM, и дадим советы о путях их преодоления. Любой проект, предполагающий не просто внедрение программного инструментария, а изменение всей стратегии и методов ведения бизнеса в компании, требует детальной проработки и подготовки к обстоятельной защите.
Необходимыми базовыми условиями развития стратегии CRM являются как минимум следующие.
Суть самого процесса защиты проекта в этом случае сводится к необходимости убедить руководство, коллег, возможно, акционеров в важности данного проекта, сформировать бюджет, определить стратегию реализации, потенциальных партнеров и поставщиков, выбрать технологический вариант решения.
В России катастрофически не хватает опыта реализации проектов в области CRM — как внутри компаний, так и у поставщиков технологических решений и бизнес-консультантов. Это приводит к тому, что неумелая или некорректная аргументация при защите проекта приводит к несоответствию ожиданий и бьет по интересам компании, репутации менеджера и поставщика услуг. В результате теряют все.
Основной задачей на данном этапе, как для
На ежегодном "съезде" всех партнеров одного из крупнейших производителей CRM-систем в мире представители данного производителя представляли новую версию технологической платформы.
В ряду планируемых изменений в структуре новой версии системы они предложили убрать из системы модуль прогнозирования, предоставляющий возможности построения красивых, но малопрактичных графиков и таблиц. "По данным опросов наших существующих клиентов, менее 10% из них пользуются функциями этого модуля. Тем, кому действительно нужны возможности прогнозирования, используют для этого встраиваемые модули сторонних производителей, — говорил в своем докладе директор по производству новых версий. — При этом разработка и поддержание этого модуля отнимает у нас существенные производственные ресурсы".
Подобное решение вызвало негативную реакцию среди партнеров, осуществляющих продажу и внедрение системы по всему миру. "С одной стороны, — говорили многие из них в кулуарах, — производитель прав. Никто практически не пользуется данным модулем. Однако его наличие [красивые яркие графики, которые динамически изменяются в соответствии с текущим состоянием] является просто необходимым при демонстрации системы высшим руководителям! Они влюбляются в него и готовы платить больше, хотя никогда в дальнейшем даже не вспомнят про этот модуль..."
Приведенный пример показывает, что ожидания руководителей предприятия при запуске проекта и реальные потребности бизнеса могут существенно различаться. Необходимо правильно подобрать критерии, представить и обосновать их на ранних этапах проекта.
В чем же все-таки заключается сложность грамотной защиты проекта CRM?
Почему мы так детально останавливаемся на этом вопросе именно на этапе защиты проекта? Разве эта работа не является основной задачей привлеченных консультантов или приобретаемой системы? Далее мы постараемся объяснить, почему эти задачи мы относим именно к этапу защиты, а не реализации проекта, и приведем реальные примеры из жизни.
Вы можете потратить несколько лет, доказывая необходимость реализации стратегии CRM в вашей компании и слышать в ответ: "Это очень важно, я понимаю, но сейчас у меня другие приоритеты". Практический опыт показал, что следующие сценарии развития ситуации могут заставить руководителя бизнеса предпринять немедленные шаги в сторону CRM.
| Сценарий | Основной движущий фактор для внедрения | В чем заключается основная потребность руководителя |
|---|---|---|
| Кризисный | Возникновение кризисной ситуации, например: |
Контроль за информацией. Систематизация деятельности сотрудников |
| Развивающий | Бурное развитие бизнеса (или потребность в развитии), которое невозможно осуществлять "по старинке". Может выражаться в следующем: |
Автоматизация рутинных операций. Контроль эффективности. Накопление и передача знаний |
| Статусный | Необходимость CRM определяется внешними факторами, например: |
Реализация условий, налагаемых внешними факторами (руководством, инвесторами и т.д.) |
В разделе "Кому не нужна стратегия CRM?" рассматриваются более подробно причины отказов. Здесь мы лишь приведем таблицу с основными причинами и возможной "домашней работой", которую необходимо проделать, чтобы бороться с каждой из указанных причин.
| Причина | В чем суть проблемы? | Домашняя работа |
|---|---|---|
| Отсутствие внутреннего спроса | Непосредственные бизнеспользователи не заинтересованы в решении задач CRM по тем или иным причинам, отсутствуют бизнес- |
Поиск и убеждение потенциальных бизнесспонсоров на самом высоком уровне. |
| Финансовые ограничения | В бюджете нет средств на CRM, финансовое руководство считает эти расходы неоправданными, предлагаемые решения выходят за рамки финансовых ожиданий | Расчет возврата на инвестиции — ROI (Return on Investment), управление ожиданиями, аналитика по расходам конкурентов на развитие CRM |
| Корпоративные ограничения | Существующие корпоративные стандарты не подразумевают использование CRM или не подходят для существующих задач | Разработка "Аналитической записки", или |
| Боязнь неудачи | Предыдущие внедрения систем, таких как ERP, привели к неудаче и разочарованию руководства в эффективности ИТ при огромных затратах времени и средств | Поиск возможных "быстрых побед" для решения конкретных локальных задач в короткие сроки и "малой кровью" |
| Нежелание принимать ответственность | Руководители/подчиненные не желают принимать решения, которые могут негативно сказаться на их карьере, — из-за этого любые инновационные идеи буксуют | Составление списка решений, "за выбор которых точно не уволят", "заговор" энергичных сотрудников, для которых это — шанс всей жизни |
Почему так важно подготовиться к проекту внедрения до его формального запуска?
Подготовка к проекту внедрения экономит вам средства. Привлекая внешних консультантов для осуществления проекта внедрения системы, вы инвестируете существенные средства в работу профессионалов. Вы должны быть уверены, что эти инвестиции будут использованы наиболее оптимально. Чем больше времени и усилий консультантов будет уходить на непродуктивное ожидание и "выуживание" информации, тем меньше конструктивных бизнес-задач они смогут решить за выделенное на проект время.
Весь успех CRM-проекта зависит от четкого определения и формулировки бизнес-целей. Речь здесь идет не о декларативных лозунгах, что с клиентами нужно быть более обходительными, а о четко сформулированных и решаемых стратегических целях. С обсуждения этих целей начинается (или должен начинаться) любой стратегический проект, так как именно на основании этих целей в дальнейшем поставщики будут предлагать свои варианты решений, а руководство — выделять средства на CRM-проект. Если у основного инициатора проекта нет четкого видения, какие бизнес-проблемы могут быть решены в ходе проекта, того же видения не будет и у руководства, и у поставщиков, и проект будет лишен основной части — смысла ("Зачем мы все это делаем?"). Примеры не четко сформулированных целей: "Повышение эффективности работы отделов продаж, маркетинга, сервиса", "Повышение прозрачности и управляемости бизнеса", "Улучшение взаимодействия между департаментами" — все эти цели неконкретны. Такие формулировки могут присутствовать только если в дальнейшем они будут детализированы и связаны с решением конкретных бизнес-проблем и достижением конкретных целей. Почему мы разделяем понятия "проблемы" и "цели"? Дело в том, что предпринимать какие-либо шаги в направлении CRM-компании побуждает либо недовольство текущим положением вещей и желание что-то поменять в существующей практике (бизнес-проблемы), либо наличие новых стратегический целей, связанных с будущим развитием компании (бизнес-цели). В целом не важно, что именно явилось источником интереса к CRM. В большинстве случаев это сочетание и того и другого.
Сложность выявления бизнес-проблем заключается в том, что часто руководство имеет достаточно абстрактное представление о проблемах собственной компании. Распространена ситуация, когда на вопрос: "Какие проблемы бизнеса побудили вас начать поиск CRM-решения?" приводятся аргументы следующего характера: "Отсутствие единой базы данных клиентов". Само по себе отсутствие единой клиентской базы еще не является проблемой для бизнеса. Реальные проблемы возникают в связи с отсутствием такой БД, но в каждом конкретном случае из-за одной и той же предпосылки возникают совершенно разные проблемы. В одной компании проблема заключается в непродуктивном использовании рабочего времени продавца и росте издержек на клиентское обслуживание в связи с отсутствием эффективной системы передачи информации. В другой проблемой является низкая эффективность маркетинговых мероприятий из-за невозможности сделать узконаправленную выборку клиентов, либо проанализировать предыдущую эффективность мероприятий. И задача инициатора проекта на данном этапе — правильно сориентировать свое руководство и вместе с ним выстроить всю цепочку от предпосылки до определения реальных бизнес-проблем. Общий принцип следующий: любая бизнес-проблема имеет денежное выражение. На чем может терять или не зарабатывать деньги ваша компания, например, из-за отсутствия единой клиентской базы?
Кстати, определенные на данном этапе бизнес-цели и бизнес-проблемы еще никак не связаны с конкретным CRM-продуктом или CRM-системой вообще. Возможно, задачи более эффективно и правильно можно решить определенными организационными и структурными мерами: перестроить систему стимулирования, усилить дисциплину, провести обучение и т.д.
Именно на этом этапе инициатор проекта дает обещания. Как решить конкретную задачу? Будет ли это работать? Что компания сможет изменить в дальнейшем? Часто для достижения поставленных целей не требуется дорогостоящий программный инструментарий или изощренная стратегия — достаточно базовых функций по учету и контролю за информацией, организационной целостности, дисциплины и мотивации. В консалтинговых компаниях существует визуальный алгоритм, позволяющий определить, какие же функции необходимы клиенту. Он называется "
Ниже приведен пример детализации возможной цели до уровня способа решения задачи.
Из рисунка видно, что для решения различных задач могут использоваться одни и те же способы. Чем более универсальными являются те или иные способы, тем выше будет их приоритет реализации в дальнейшем.
Почему важно провести эту работу в укрупненном виде, уже на этапе внутренней продажи проекта? Потому что убедительным для руководства является решение конкретных проблем бизнеса, а не сам факт использования "крутой" или "навороченной" современной системы. Не одно хорошее и благородное начинание разбилось о камень непонимания со стороны руководства, потому что при обосновании проекта для руководства использовались такие понятия, как "самая современная технология", "революция в стандартах", "требования рынка".
Также на этом предварительном этапе происходит оценка трудозатрат по проекту и появляется представление о том, что может быть реализовано и какими средствами. Определив проблемы, задачи и способы решения, а также поняв специфику бизнеса компании, можно предварительно определить перечень конкретных действий и функций и понять, насколько компании "по силам" сейчас браться за решение этих задач. При этом важно: а) представлять возможности и специфику функциональности различных систем; б) знать на примерах других проектов, как данная функциональность может быть применена для решения конкретных бизнес-проблем.
Часто компании, переводя описание своих бизнес-задач и целей в список конкретных методов и функций, попадают в распространенную ловушку: не имея представления о существующих стандартных возможностях систем автоматизации, им сложно правильно расставить приоритеты в автоматизации.
Например, руководство компании в качестве приоритетной задачи выделило необходимость информирования клиентов о важных событиях — ключевых транзакциях по счетам, специальных условиях и скидках, новых интересных для клиента продуктах и т.д. В качестве средств информирования можно использовать звонок менеджера по продажам (в этом случае функция, ответственная за информирование, заключается в автоматическом назначении менеджеру по продажам соответствующей задачи — позвонить клиенту). С другой стороны, можно использовать средства рассылки по электронной почте, SMS, факсу и автоматический обзвон автоинформатором. Сложность реализации каждой из этих функций может существенно превышать экономический эффект от ее внедрения. Не имея представления о трудоемкости и ресурсоемкости каждой из этих функций, оценить целесообразность их использования будет достаточно сложно.
Есть риск, что составленный перечень требований к функциональности может оказаться неприменимым, т.к. не будет ни одной системы, обладающей всеми функциями. Либо формулировка требований будет неконкретной, и под нее можно будет подвести практически любую систему.
Вот пример, иллюстрирующий приведенную выше схему. "Соблюдение технологии продаж" может заключаться в следующем:
При этом один продукт позволяет "прописать" цикл продажи в указанном виде (в виде стадий и шагов). Другой имеет набор инструментов для каждой стадии: специализированные формы и сценарии квалификации клиента, анализа потребностей клиента, возможность задать правила предложения определенных продуктов (если клиент обладает заданным набором характеристик, то при любом контакте клиента с организацией система рекомендует предложить ему тот или иной продукт) и т.п. И соотнесение бизнес-задачи и функций CRM-системы требует знания этих функций.
К сожалению, только реальный опыт дает понимание сложности внедрения той или иной функциональности под специфические потребности бизнеса. А, следовательно, уже на данном этапе опытный консультант может скорректировать ожидания компании и правильно сориентировать ее руководителей, выявив те задачи, которые при минимальных затратах позволяют достичь максимального эффекта.
Таким образом, при грамотном подходе к защите проекта у его инициатора должно быть четкое, согласованное видение того, какие проблемы планирует решить компания, какие функции для этого необходимы, какие дополнительные работы придется совершить и какие затраты времени и средств для этого понадобятся. Вся эта информация должна войти в обоснование проекта. Рамки проекта на данном этапе должны быть максимально конкретными и целенаправленными.
Все поставщики решений и консалтинговые компании с радостью предложат осуществить работы по определению и детализации бизнес-проблем и целей. Соответствующая услуга, которая может называться "предпроектное обследование", "постановка задачи", "разработка технико-экономического обоснования", входит в перечень возможностей любого CRM-поставщика. Тем не менее полностью доверять сторонним консультантам в этих вопросах нельзя. "Независимые" консультанты (т.е. компании, не предоставляющие услуги по внедрению конкретных систем) в своих оценках будут так же оторваны от реальных возможностей современных систем, как и вы сами. "Зависимые" консультанты будут ориентироваться в первую очередь на возможности собственных продвигаемых систем автоматизации.
Любой проект в области ИТ — это всегда компромисс между несколькими противоречивыми интересами, такими как:
Помните басню про жадного купца, который пытался сшить побольше шапок из одной овчинки? В результате он выторговал семь шапок, но каждая из них получилась настолько маленькой, что не налезала на голову.
Та же ситуация наблюдается, когда руководитель предприятия ставит перед проектной командой задачу по принципу: "Нам нужна максимальная функциональность про запас за минимальные деньги! Да, и она нужна нам вчера". Результатом будет пропорциональное увеличение рисков проекта, и весь экономический эффект от внедрения может быть поставлен под удар.
Очевидно, что попытка достичь максимума по каждому из приоритетов одновременно равносильна попытке сшить как можно больше шапок из одной овчинкиѕ Управление проектом — это умение постоянно балансировать между существующими интересами, чтобы каждый получил заслуженный приоритет, сохраняя при этом устойчивое равновесие.
Умение соблюсти баланс этих интересов — основной навык, необходимый руководителю проекта внедрения CRM для обеспечения своего личного и корпоративного успеха.
Многие компании экономят каждую копейку на закупках различной техники и расходных материалов, однако проявляют неосведомленность в процессе выбора информационных систем, таких как CRM. А принятие решения по закупке автоматизированной системы на основании поверхностного изучения нескольких рекламных буклетов и пары маркетинговых презентаций может дорого обойтись.
На рынке предлагаются сотни систем, название которых содержит модную аббревиатуру "CRM", однако комплексное "построчное" сравнение функциональных и технических особенностей всех возможных вариантов может отнять годы работы лучших сотрудников. Даже коммерческие исследования с независимым описанием и сравнением существующих решений не проясняют ситуацию.
Побывав "по обе стороны баррикад", мы предлагаем простую, но действенную методологию для отсева "мишуры" и выбора нескольких возможных систем, в нюансы которых уже имеет смысл вникнуть более подробно. Это позволит сэкономить время как ответственным сотрудникам, так и потенциальным поставщикам.
Первый шаг в выборе поставщика любой информационной системы — составление так называемого "короткого списка" претендентов (не более 2–3 систем), которые уже могут участвовать в тендере. Выбор окончательной системы по результатам тендера всегда является прерогативой высшего руководства, часто представляет собой в большей степени политический, нежели экономический процесс и может базироваться на субъективных факторах. В данной статье мы не рассматриваем факторы, влияющие на окончательный выбор системы. Задачу, которую обычно ставит руководство компании перед будущим руководителем проекта, можно сформулировать следующим образом: "Вы нам представьте список из 2–3 вариантов решений, каждое из которых подойдет нам по требованиям. А мы уже выберем лучшего среди равных". Таким образом, каким бы нелогичным и субъективным ни было решение руководства о выборе той или иной системы, оно не станет причиной неуспеха всего проекта.
Западные эксперты считают, что особое значение для экономии времени и сил имеет процесс рассмотрения первичных предложений и ознакомительных презентаций. Чтобы этот процесс сразу направить в правильное русло, в первую очередь необходимо определиться с собственными ожиданиями: какие ключевые задачи вновь приобретаемая система должна будет решать?
При выборе нужно отдавать предпочтение системам, которые помогут быстрее и эффективнее достичь ожидаемых целей, при этом стараясь меньше отвлекаться на всевозможные "спецэффекты".
| Методология быстрого отсева поставщиков CRM-систем | |
|---|---|
| Инструкция для формалиста | Какие документы нужно использовать? |
| Сформулируйте для себя: См. раздел "Знайте свои цели" или "Пример списка квалификационных вопросов" |
"Служебная записка" (для внутреннего использования) для всех участников процесса отбора, регламентирующая процесс выбора. Обязательна подпись ответственного руководителя. "Список квалификационных вопросов" (для внешнего использования). Рассылается всем заинтересованным поставщикам на любые вопросы, связанные с проектом. "Один день из жизни". Сценарий (или несколько сценариев), описывающий "человеческим языком" требования пользователей к системе. |
| Проанализируйте полученные от поставщиков заполненные анкеты "Список квалификационных вопросов" Сформулируйте ответы на вопросы: Отбросьте явных "аутсайдеров". Пошлите им письмо с благодарностью за участие (хорошие отношения с поставщиками пригодятся в будущем!) |
Ревизия "Служебной записки", если необходимо. Таблица соответствия требованиям. Простая таблица, в которой можно отметить плюсы и минусы по наиболее важным параметрам для всех предлагаемых систем. Письмо "Благодарность — отказ" |
| Выслушайте презентации/демонстрации поставщиков: |
Наброски "Технического задания", чтобы умные мысли записывать туда по горячим следам. Альбом для рисования каракуль, чтобы выдержать многочисленные скучные презентации об одном и том же |
| Составьте "короткий список" решений по результатам презентаций: См. раздел "Отбираем кандидатов" |
Детальные наброски "Технического задания" (именно наброски, потому что полноценное ТЗ можно будет составить только после выбора поставщика, и только совместно с ним). Письмо "Благодарность — отказ" |
| Рассмотрите |
Дополнительные инструменты поставщиков (например, бесплатная демонстрационная версия системы или результаты бесплатного экспресс-анализа бизнес-процессов), если они их предлагают. Докладная записка руководству с обобщением результатов выбора и рекомендациями (желательно скрепить подписями других членов команды и заинтересованных пользователей во избежание обвинений в предвзятости) |
| Минимизируйте ущерб от субъективизма руководства: |
"Служебная записка" (для внутреннего использования) из пункта 1. Докладная записка для руководства из пункта 5. Зловещее (для поставщиков) письмо "Благодарность — отказ". Письмо выигравшему поставщику с указанием условий и плана дальнейших действий |
Исследования в США и Европе показали, что неспособность сформулировать конкретные ожидания остается главной причиной провала стратегических инициатив в области CRM. Даже в условиях экономической стагнации и жесткой экономии в списке причин задержек при внедрении "Прекращение финансирования" стоит после пункта "Отсутствие четкой стратегии".
Решение этой проблемы начинается в процессе первичного отбора возможных систем. В запросе на предложения необходимо сразу постараться сформулировать основные критерии оценки эффективности проекта — такие, как увеличение продуктивности работы (насколько?) и возврат на инвестиции (в каком объеме?). Вы можете спросить поставщиков, как они могут помочь в соблюдении этих критериев, а также попросить рекомендации клиентов, которые использовали эти системы для достижения похожих целей. Это возымеет значительно больший эффект, чем выбор системы на основе списка функциональности.
Как это ни странно, сформулировать практичные и достижимые цели проекта в большинстве случаев бывает довольно сложно, особенно когда речь идет об автоматизации "с нуля". Записав две-три избитые фразы типа "Увеличить объем продаж" или "Оптимизировать процесс прохождения сервисных заявок", менеджер часто впадает в глубокое раздумье: а в какой мере информационная система действительно сможет обеспечить такие результаты? Как определить, действительно ли увеличение продаж произошло благодаря внедрению системы, или просто имело место сезонное колебание?
Выше мы уже останавливались коротко на методологии определения бизнес-целей. Ниже мы также более подробно остановимся на процессе формализации и анализе бизнес-требований, который призван превратить список целей и бизнес-проблем в конкретные формальные требования по проекту. Насколько глубоко вы собираетесь самостоятельно пройти от определения целей и проблем до формализации конкретных функциональных требований прежде, чем обратитесь к поставщикам, а какую часть работы переложите на них уже после подписания договора, — решать вам.
Для того чтобы сократить число возможных систем до трех (оптимальное число для участия в комплексном тендере), можно обратиться за помощью к специализированным консультантам или исследовательским агентствам. Многие из этих компаний собирают информацию о существующих продуктах и постоянно отслеживают все изменения и достижения в данной предметной области. Поэтому они могут помочь более объективно сравнить функциональность и ценовые характеристики различных систем.
Многие компании уже пользуются услугами подобных консалтинговых компаний или исследовательских агентств в других областях, однако мало кто прибегает к их услугам для квалифицированного отбора технологических решений. Участие внешнего консультанта на первом этапе отбора решений-кандидатов позволит не только сократить время на процесс отсева, но и обеспечит непредвзятую
Вы будете удивлены, узнав, сколько ИТ-компаний в России специализируется на предоставлении подобных услуг, причем делают они это на достаточно высоком уровне и за приемлемые деньги (средняя цена подобных услуг в Москве составляет 3–10% от предполагаемого бюджета внедрения системы в зависимости от роли и меры ответственности внешнего консультанта).
Если все-таки вам трудно ограничить список кандидатов, не поленитесь связаться с компаниями — клиентами потенциальных поставщиков и поинтересуйтесь их мнением. В большинстве случаев, если вы ничего не продаете и не являетесь прямым конкурентом, менеджер другой компании с удовольствием расскажет все, что он об этом думает.
Пожалуй, наиболее эффективный путь отбора кандидатов — рассылка списка обязательной функциональности предлагаемой системы с запросом квалифицированного ответа. Такую рассылку можно легко и быстро сделать по электронной почте и не утруждать ни себя, ни других презентацией функций, которые вам не нужны.
Можно, например, подготовить список из 15 вопросов, каждый из которых будет посвящен определенной проблеме, с которой предполагаемая система должна справиться. Далее этот список можно разослать максимальному числу претендентов. Задавать более 15 вопросов не имеет смысла, потому что большинство компаний не будет тратить время на то, чтобы на все из них обстоятельно ответить, менее 10 вопросов не позволит квалифицированно определить различия предлагаемых систем.
Возможно, для составления короткого списка вопросов вам потребуется участие всей команды, включая руководителей, технических специалистов и конечных пользователей, — чтобы вопросы были разноплановыми и максимально точными.
Если вы спросите, можно ли управлять продажами через предлагаемую систему, то, скорее всего, получите развернутый ответ, не имеющий конкретной экономической пользы, например: "Наша система обладает всеобъемлющей функциональностью в области управления продажами". Если же вы сформулируете свой вопрос иначе, указывая конкретные требования, например: "Секретарь принимает звонок и вводит данные в систему. Далее система должна выбрать менеджера по работе с этим клиентом и поставить ему задачу связаться с клиентом и выяснить детали в заданный срок. Возможно ли это? Требуется ли дополнительное программирование для реализации этой функции?", то поставите поставщика перед необходимостью четко раскрыть ограничения системы: "Реализация данной функции потребует определенных дополнительных настроек, однако успешный опыт использования аналогичного решения существует в компании N".
Ключевым фактором успеха для покупателя является понимание того, что он ожидает увидеть в качестве ответов поставщиков. Большинство продавцов будут отвечать то, что, по их мнению, должно понравится покупателю, или будут слишком пространны в своих ответах, обходя существующие ограничения системы, если формат запроса позволяет это сделать. Составление списка вопросов, которые могут дать представление о возможностях системы и ее поставщика, и при этом не дают простора для того, чтобы вешать лапшу на уши, — большое искусство, требующее определенных навыков и сноровки.
Чтобы помочь вам в этом процессе, мы подготовили пример, который может дать начальную почву для размышлений. При закупке небольших систем (например, на 5–10 рабочих мест) его можно использовать в качестве формального "Запроса на предложения" (
| Пример списка квалификационных вопросов |
|---|
Компания N рассматривает возможность приобретения CRM-системы для снижения издержек на операционное обслуживание клиентов и увеличения объемов кросс-продаж между различными подразделениями холдинга. Мы планируем автоматизировать до 30 рабочих мест в течение первого года работы, включая отдел маркетинга (5 чел.), отдел продаж (10 чел.), отдел поддержки (10 чел.) и административные службы (бухгалтерия, руководство, ИТ — всего до 5 чел.) Наша компания заинтересована в долгосрочных отношениях с профессиональным поставщиком систем, отвечающим нашим требованиям для осуществления комплексного внедрения, обучения и технической поддержки данного решения. Мы предполагаем провести выбор поставщика в течение 4-х недель с момента рассылки данного запроса и ожидаем, что процесс внедрения будет осуществлен в течение 3-х месяцев с момента выбора поставщика. Пожалуйста, ответьте на предложенные ниже вопросы, чтобы мы могли лучше понять возможности предлагаемых вами решений. Детальные требования и технические спецификации будут предоставлены только компаниям, прошедшим первичную квалификацию (после подписания соглашения о конфиденциальности). |
Поставщики, которые действительно заинтересованы в вас как клиенте, представят развернутый ответ в кратчайшие сроки. Подобный подход позволяет сузить круг потенциальных решений с десятков до единиц. Практический опыт показывает, что составление квалифицированного списка вопросов и правильная обработка результатов позволяет просеять 30–40 поставщиков и выбрать из них 3–4 в течение недели.
Когда количество поставщиков, составляющих "короткий список", не превышает 3–4, с ними можно организовать более тесное и конструктивное взаимодействие. В частности, можно подписать Соглашение о конфиденциальности, разослать технические спецификации и бизнес-требования, а также расширенный список квалификационных вопросов, который иногда может включать до 100 пунктов.
Примерный список критериев выбора решения CRM
Вот список критериев, которые наиболее часто используют компании при выборе решений CRM (в скобках указан весовой коэффициент данного параметра, %).
Соответствие запрашиваемой функциональности (50%) Составить полный список необходимых функций с указанием приоритетов (или этапов) и сложности реализации — shopping list.
Попросить поставщиков указать, какие из функций входят в базовую функциональность, какие требуют доработки.
Сделать сквозной анализ каждой функции.
Цена решения (30%) Разброс цен может быть огромным — от $5000 до $500 000 за один и тот же набор функциональности.
С поставщиками можно и нужно торговаться.
Общая стоимость владения (10%) Исходная цена решения — только 20–30% от общей стоимости владения.
Используйте косвенные факторы для оценки ОСВ — стоимость дополнительного рабочего места, обучения, технической поддержки и т.д.
Какие гарантии дает поставщик?
Масштабируемость (5%) Что будет с предлагаемым решением через 2–3 года, когда ваш бизнес вырастет? Какие сценарии предлагает поставщик?
Опыт применения в России (5%) Кто уже использует решение в России, и насколько эффективно? Можно ли организовать визит к существующему клиенту?
Прежде чем вы начнете проект по внедрению системы CRM, консультанты компании-подрядчика должны лучше понять ваш бизнес, процессы, типы данных. Для того чтобы проектная команда получила представление о работе вашей компании, необходимо предоставить ей доступ к соответствующим источникам информации, включая Web-сайт, маркетинговые материалы, внутренние регламенты и процедуры или другие документы по вашей компании и индустрии в целом.
Все требования можно условно разделить на функциональные и нефункциональные. Функциональные требования определяют, что именно система должна уметь делать. Нефункциональные требования связаны с характеристиками системы — такими, как производительность, устойчивость, системные интерфейсы, ограничения по дизайну. Требования также могут включать задачи и цели системы, которые предполагается достигнуть.
Основной целью анализа требований является формализация детальных спецификаций, которые однозначно определяют, что должна представлять собой система после окончания проекта внедрения.
Детальные спецификации — это то, что можно характеризовать следующими параметрами:
Первым этапом формализации требований является их определение. Правильно реализованный процесс определения требований сэкономит огромные ресурсы на последующих этапах разработки программного обеспечения. Всегда проще и эффективнее создать приложение после того, как все требования к нему собраны и описаны, чем делать это в процессе их сбора.
Главная цель процесса определения требований — снабжение проектной команды объективной и целостной информацией для составления плана-графика проекта и функциональных требований к системе.
Основная сложность и ответственность на этапе определения требований заключается в том, что необходимо определить все требования, которые можно считать необходимыми и достаточными.
Условие необходимости подразумевает, что каждое из определенных требований действительно необходимо бизнесу и в список не попали те требования, которые являются излишними.
Условие достаточности подразумевает, что список содержит все необходимые бизнесу требования, ни одно не было забыто. Соблюдение условия достаточности требует от аналитика, составляющего список требований, определенного опыта и практических знаний в данной индустрии. Он должен уметь "предвидеть" вопросы, которые сотрудники компании-заказчика могли упустить из виду или посчитать несущественными из-за отсутствия опыта решения подобных задач.
Так как каждый проект всегда уникален, не существует готовой "книги рецептов" для определения требований. Каждый проект требует собственной стратегии для этого процесса в соответствии со спецификой вашей компании.
Если вы никогда раньше не участвовали в процессе сбора и формализации требований, вам будет трудно четко и однозначно сформулировать задачи автоматизации. Однако существует много источников, которые могут помочь в выполнении этого "домашнего задания". Приведем основные принципы по организации процесса формализации собственных требований.
Следует мысленно разделить процесс определения своих целей на три основных этапа:
Эти три этапа можно разделить на следующие основные шаги.
Избегайте следующих "классических" проблем при анализе потребностей:
Проблемы масштаба можно избежать, если начать анализ потребностей "сверху", двигаясь от общего к частному, определив изначально общие границы и задачи проекта. Следующие факторы при этом являются существенными:
Организационные факторы.
Факторы среды:
Проблема понимания может возникнуть из-за следующих причин:
Требования бизнес-пользователей не всегда могут быть сразу корректно сформулированы еще до начала проекта. Требования к системе, таким образом, будут постоянно меняться в процессе разработки. По мере развития процесса разработки, как пользователи, так и разработчики постоянно приобретают более глубокое понимание проблемы. Дополнительные знания приводят к необходимости добавить новые или изменить существующие требования. Для того чтобы эффективно работать в изменчивой среде потребностей бизнеса, процесс детализации потребностей должен происходить постоянно и итеративно.
Для наших целей бизнес-процессом называется определенная последовательность действий или процедур, которые должны быть осуществлены для выполнения поставленной задачи. Какие-то процессы могут быть формально описаны как четкая последовательность действий в регламенте, следование этому регламенту является обязательным. Другие процессы могут быть неформальными, они могут быть описаны на уровне общих принципов, не обязательных для четкого следования. Некоторые компании полагаются на "принятую мировую практику" того, как должны выполняться те или иные действия — они могут обходиться без письменных регламентов.
Проект внедрения CRM обязательно будет связан с существующими бизнес-процессами в вашей компании. Какие-то из процессов нужно будет создать или перестроить. Консультантам потребуется собрать необходимую информацию для понимания и лучшего планирования ваших бизнес-процессов.
Компания будет лучше подготовлена к запуску проекта внедрения, если вы выполните следующие шаги на этапе определения своих задач и потребностей.
Рассматривая собственные бизнес-процессы, вы можете сформулировать "внутреннее понимание проблем", т.е. попытаться ответить на вопрос: "Что не так?" Например:
| Неправильно | Проект должен гарантировать, что продавец сможет аккуратно подобрать конфигурацию и предоставить заказчику четкую спецификацию для заказа. |
| Правильно | Продавцы не могут аккуратно подобрать конфигурацию, что приводит к неточным спецификациям при заказе |
По мере того как вы формулируете свои задачи и вам становятся понятны корневые проблемы в области бизнес-процессов, можно приступать к поиску путей их решения. Вы можете начать этот процесс еще до запуска проекта, а затем проектная команда со стороны подрядчика сможет дополнить/исправить этот список. Констатация возможного решения не должна описывать задачи программного приложения или какие-либо другие детали; она должна четко определять, как необходимо подходить к решению этой проблемы. Например:
| Неправильно | Создать приложение для продавцов, в котором они смогут выбрать конфигурацию и сформировать правильный заказ. |
| Правильно | Предоставить инструмент для конфигурации заказа в соответствии с существующими правилами |
Не рассчитывайте, что вы сможете с первого раза составить детальный и целостный документ. Однако хорошо выполненное "домашнее задание" существенно повысит ваш авторитет в глазах приходящих консультантов и снизит вероятность того, что вас обманут.
Успех любого проекта зависит от квалификации и опыта определенной команды людей (а также от степени их концентрации на задачах проекта). Все участники команды должны быть заинтересованы в успехе. Они должны иметь возможность полагаться как на свой собственный опыт, так и на возможности других участников команды, чтобы совместно сформировать среду эффективного взаимодействия. Вопросы психологической совместимости могут играть в процессе построения эффективной команды принципиальную роль. Со своей стороны, формируя команду участников того или иного проекта, подрядчик выбирает тех сотрудников, которые могут выступать экспертами в данной отрасли, обладают необходимыми знаниями по функциональности систем CRM, а также способны управлять постоянно изменяющимися запросами.
Со стороны заказчика в команде должны участвовать сотрудники организации, обладающие знаниями своего бизнеса и организационной структуры компании. Они способны принимать ответственные решения, учиться и перенимать профессиональный опыт, а также применять его в повседневной работе для развития своей компании.
Приведенная ниже диаграмма показывает стандартную структуру проектной команды для сложного проекта внедрения. Проект внедрения системы на десяти рабочих местах может и не потребовать такой сложной структуры; однако если речь идет о десятках рабочих мест, все элементы этой структуры становятся ключевыми.
Рассмотрим кратко основные элементы командной структуры проекта.
| Управляющий комитет | Ключевым фактором успеха любого инновационного проекта является поддержка высшего руководства. Однако современный руководитель предприятия не может себе позволить повседневное участие в решении задач проекта. Функция управляющего комитета, в который входят руководители компаний заказчика и подрядчика, заключается в решении кризисных и нестандартных ситуаций, которые не могут быть решены сотрудниками на более низких уровнях управления. Наличие такого комитета и его "точечная" активность позволяет избежать застоя в проекте и "патовых" ситуаций с подрядчиками. Часто говорят, что в управляющий комитет должны войти люди, которые "слишком заняты, чтобы участвовать в проекте, однако слишком важны, чтобы полностью упускать этот проект из виду" |
| Менеджер проекта | Главный элемент любой проектной команды — менеджер проекта, или руководитель этой команды. Это конкретный человек, обладающий опытом и наделенный полномочиями. В большинстве случаев функцию менеджера проекта выполняет профессиональный консультант — сотрудник компании подрядчика. |
| Контроль качества | Этот элемент необязательно будет присутствовать в вашей проектной команде, однако мы настоятельно рекомендуем вводить независимую функцию контроля качества на любом проекте с количеством рабочих мест более 20–30. Менеджер проекта и представители компании-подрядчика в процессе реализации проекта могут упустить из виду какие-то важные функциональные элементы, внешние или внутренние факторы, влияющие на успех проекта в целом. Специалист по контролю качества также может выступать гарантом соответствия предлагаемого решения современным технологическим и бизнес-стандартам. Функцию контроля качества может выполнять отдельный сотрудник подрядчика, не участвующий в ежедневной работе над проектом, или привлеченный внешний эксперт. |
| Поддержка производителя | Если вы планируете внедрение современной инновационной технологии, или выбранное вами решение само по себе уникально для вашей индустрии или региона, имеет смысл заручиться поддержкой производителя программного обеспечения. Такая поддержка сможет гарантировать максимально быстрое решение возникающих технических и организационных проблем. В отдельных случаях (в первую очередь, когда проект подразумевает внедрение от 100 рабочих мест) производитель может выслать своего специалиста непосредственно к вам на проект. Однако накладные расходы, связанные с его проживанием и работой, скорее всего, лягут на вашу компанию. |
| Техническая команда Команда бизнес-анализа Системная поддержка и обучение |
В непосредственном подчинении менеджера проекта будут находиться специалисты по решению различных задач — технических, аналитических и поддерживающих. По мере изменения потребностей проекта может меняться и состав этих подкоманд |
Проект по внедрению любой информационной системы требует активного взаимодействия участников команды, как со стороны заказчика, так и подрядчика. Цель взаимодействия — обеспечить управление ожиданиями сторон в рамках проекта, и как результат — максимальное соответствие результирующей системы исходным потребностям бизнеса. Эффективное взаимодействие также необходимо для того, чтобы функционирование и развитие системы в дальнейшем встречало понимание со стороны пользователей и обслуживающего технического персонала.
Мы предполагаем, что как минимум следующие "роли" должны войти в проектную команду со стороны заказчика:
Лидер группы заказчика работает в постоянном контакте с менеджером проекта со стороны подрядчика, следя за тем, чтобы все поставленные задачи были выполнены в срок и правильно. Если возникают какие-либо вопросы, лидер группы заказчика совместно с менеджером проекта подрядчика обсуждают эти вопросы и находят взаимовыгодное решение. Функциональные обязанности лидера группы заказчика:
Лидер группы заказчика выступает для сотрудников компании подрядчика в качестве главной "точки контакта" — через него происходит доступ к информации, контакт с другими сотрудниками организации заказчика.
Лидер группы заказчика должен обладать необходимыми полномочиями для того, чтобы утверждать технические требования, принимать работу, авторизовать расходы в рамках выделенного на проект бюджета. Если лидер группы заказчика не наделен подобными полномочиями в полном объеме (или осознанно не хочет пользоваться этими полномочиями, чтобы не брать на себя дополнительную ответственность), он превращается в лишнее связующее звено между подрядчиком и сотрудниками своей организации, которые действительно принимают решения. Это, в свою очередь, приводит к затягиванию проекта, неразберихе, многократным переделкам и неэффективному использованию ресурсов.
Для каждого из основных функциональных блоков системы в вашей организации — продаж, маркетинга, поддержки, удаленных агентов и т.д. — должен быть назначен ответственный специалист по использованию системы. Каждый такой специалист должен быть знаком с операционными процедурами, связанными с использованием соответствующих функциональных модулей. После окончания процесса внедрения он будет выступать основным "носителем знаний" по возможностям системы для дальнейшего развития и обучения пользователей.
Обязанности специалиста по использованию системы:
Вы должны определить главное лицо, ответственное за все вопросы или проблемы, возникающие в процессе использования системы. Специалист по поддержке должен обладать всесторонним пониманием процессов работы системы и уметь принимать оперативные технические решения.
Обязанности специалиста по поддержке системы включают:
Системный администратор отвечает за аппаратное и программное обеспечение, необходимое для эффективной работы системы в целом — операционной системы, сервера баз данных и т.д. Системный администратор должен обладать необходимой квалификацией для настройки и поддержки данного аппаратного и программного обеспечения или должен пройти соответствующие курсы обучения для приобретения этих навыков в необходимом объеме.
Обязанности системного администратора:
Производители систем и компании-интеграторы обычно предоставляют специализированные курсы обучения для системного администратора и резервного сотрудника — по вопросам безопасности, администрирования прав доступа, резервного копирования и архивирования данных и других административных функций.
Во многом успех проекта зависит от квалификации и способностей руководителя проекта со стороны подрядчика, который отвечает за общий ход реализации проекта. Он координирует ежедневные задачи всех участников команды и отслеживает статус по каждой задаче или контрольной точке.
Руководитель проекта со стороны подрядчика встречается с лидером группы заказчика для обсуждения статуса продвижения по каждой из задач проекта и разрешает возникающие противоречия или недопонимания. Прямые обязанности менеджера проекта включают:
Если возникают задержки в текущем графике реализации или другие проблемы, руководитель проекта отвечает за их разрешение после консультации с лидером группы заказчика.
Проектная команда подрядчика состоит из нескольких квалифицированных специалистов. Они назначаются руководителем проекта в соответствии с потребностями проекта. Основная задача специалистов — сбор и формализация требований, внедрение системы в требуемом объеме, настройка, проверка работоспособности и т.д.
Следующие роли специалистов подрядчика могут быть задействованы в вашем проекте (один специалист может сочетать в себе несколько ролей одновременно, если его квалификация позволяет это сделать).
Правильное планирование — половина пути к успеху, когда речь идет о внедрении сложной информационной системы. На этапе запуска проекта специалисты вашей компании совместно с внешними консультантами подрядчика определяют потребности бизнеса и составляют план внедрения системы. Они также определяют методы конвертации данных и формулируют риски и факторы оценки успешности проекта.
На основе информации, собранной во время предварительных встреч по проекту, создается план-график проекта. Этот план является основным указателем на пути продвижения от одной стадии реализации проекта к следующей. План модифицируется по мере реализации проекта, чтобы соответствовать всем запросам, которые не могли быть четко идентифицированы на первых этапах. В дополнение к этому специалисты проектной команды отслеживают все вновь возникающие сложности и ограничения — для того, чтобы соответствующим образом через систему управления запросами вносить изменения в план-график проекта и документацию.
Все это делается для того, чтобы обеспечить "управление ожиданиями", т.е. сделать процесс реализации проекта максимально прозрачным для всех его участников. В каждый момент времени, вне зависимости от того, насколько далеко текущий план проекта эволюционировал относительно начальной бизнес-концепции, проект соответствует ожиданиям заказчика по срокам, объемам выполненной работы, функциональным возможностям системы. При этом проект соответствует и ожиданиям компании-поставщика решения по срокам, бюджету, накоплению профессионального опыта.
Расписание событий, представленное в план-графике проекта, строится на основе ключевых контрольных точек, которые определяются требованиями бизнеса и корпоративного распорядка. Например, может потребоваться учесть корпоративные события или праздники, которые попадают на период реализации проекта, определить сроки установки и конфигурирования аппаратного и программного обеспечения в соответствии с графиком их поставки, привязать срок сдачи проекта в целом или каких-либо его этапов к ключевым событиям (началу сезона продаж, слиянию компаний, собранию акционеров и т.д.).
План-график проекта проще всего создать в среде Microsoft Project или другой автоматизированной системе управления проектами, которая принята в вашей компании или у подрядчика. Необходимо, чтобы эта система позволяла создавать отчеты по любым аспектам текущего состояния проекта, отслеживать ключевые контрольные точки, задержки в расписании, сравнивать исходный план с существующим на текущий момент прогрессом.
Контроль за ходом развития проекта происходит на основе формальных статусных отчетов (status report), а также неформальных встреч и обсуждений. Такой подход позволяет разрешать все вопросы и противоречия на ранних этапах их возникновения и гарантирует, что усилия по внедрению соответствуют задачам, определенным в исходных документах.
За счет использования плана-графика проекта достигается следующее:
Проект внедрения системы CRM состоит из следующих основных этапов (некоторые могут осуществляться параллельно):
Очень важное событие в истории проекта внедрения. Напряжение, связанное с процессом выбора системы и поставщика, уже позади. С другой стороны, участники проекта еще не погрузились в рутину внедрения, многие даже не понимают своей роли в проекте. Грамотно проведенная встреча по запуску проекта может сэкономить нервы и ресурсы на последующих этапах, когда оправдания типа "я думал(а), что нужно делать такѕ" и "мне никто не сказал, что я должен(на) подготовить эти документыѕ" начнут сыпаться со всех сторон.
Встреча по запуску проекта планируется с ключевыми менеджерами и техническими сотрудниками. Мы очень рекомендуем, чтобы лидер группы заказчика, бизнес-заказчик из числа топ-менеджмента, специалисты по использованию системы участвовали в этой встрече, так же как и другие сотрудники, которые должны внести вклад в процесс внедрения системы. Во время встречи участники стараются максимально глубоко понять объемы работ, общее направление развития и ожидания руководства.
Во время встречи по запуску проекта решаются следующие вопросы:
Имея более четкое представление о поставленных целях, профессиональная команда подрядчика может лучше определить ключевые контрольные точки и события. Приоритеты к моменту запуска проекта могут сильно измениться относительно тех, что были сформулированы в процессе предварительных обсуждений. На встрече по запуску проекта определяются средства взаимодействия между участниками команды, а также формат отношений с другими сотрудниками компании заказчика.
После встречи по запуску проекта проектная команда должна обладать необходимой информацией для раскладки процесса внедрения, выделения ресурсов, составления расписания и распределения задач между исполнителями — определить потребности, конвертацию данных, установку и конфигурирование системы, тестирование и интеграцию. График встреч проектной команды, интервью с ключевыми менеджерами и проектным персоналом, доступность аппаратного и программного обеспечения — все эти параметры нельзя упускать из виду, чтобы гарантировать, что процесс настройки, тестирования, установки, обучения и интеграции уложится в запланированные рамки.
План включает ключевые контрольные точки, действия ответственных сотрудников с обеих сторон. Исходный план-график, который, возможно, составлялся на этапе выбора решения, должен быть расширен и уточнен в соответствии с текущими потребностями бизнеса. После утверждения заказчиком план-график служит основой для дальнейшего развития проекта.
В рамках этой стадии реализации проекта необходимо определить потребности каждой из групп потенциальных пользователей системы. Определение функциональных потребностей предполагает серию интервью, проводимых членами проектной команды с руководителями и сотрудниками различных департаментов компании. Посредством этих интервью мы определяем и описываем следующие составляющие бизнеса:
На этом этапе специалисты не пытаются построить детальный дизайн системы, а просто определяют ключевые функциональные требования и расставляют приоритеты по важности и сложности реализации для каждого из требований. Они также пытаются определить наиболее эффективные пути достижения поставленных целей по управлению клиентскими взаимоотношениями. Задача заключается не просто в том, чтобы перенести существующие процессы на новую платформу, но и в том, чтобы найти пути улучшения их работы за счет использования новых технологий и функций системы.
По окончании серии интервью готовится документ по функциональным требованиям. Он определяет все ключевые функциональные требования. Он также определяет наиболее критичные модификации, которые необходимо внести в систему прежде, чем можно будет проводить обучение пользователей и установку приложений на рабочих местах.
Данный документ необходим не только для того, чтобы формально зафиксировать функции, которые система должна осуществлять. Он также дает возможность руководству компании заказчика принимать взвешенные решения об использовании существующего бюджета на те из задач, которые являются наиболее приоритетными и при этом имеют минимальную стоимость реализации.
В процессе реализации проекта команда внедрения осуществляет доработки системы в соответствии с требованиями бизнеса. Все изменения и доработки разбиваются по фазам в зависимости от приоритета задачи и сложности ее реализации. Для каждой фазы определяется, какие функции должны быть реализованы. Насколько это возможно, каждое требование разбивается на минимальные блоки, которые можно использовать и тестировать по отдельности. Таким образом, достигается максимальная скорость ввода реализованной функциональности в эксплуатацию для конечных пользователей, чтобы предоставить им возможность протестировать данную функцию и начать ее использование.
Каждая доработка документируется и утверждается прежде, чем начинается ее реализация. Каждое изменение исходной системы сопровождается оценкой по объемам ресурсов, а также временным диапазоном, необходимым для реализации и тестирования данной функции. Форма документирования доработки включает следующие параметры:
После утверждения данного изменения заказчиком оно включается в план-график проекта, и на него выделяются соответствующие ресурсы. После этого заказчик получает обновленный план-график проекта с учетом новой задачи.
Мы уверены, что лучший способ создания хорошей системы — постоянный контакт с конечными пользователями этой системы в процессе внесения в нее доработок и изменений. Когда задача по доработке утверждена и запущена в работу, специалист вносит соответствующие исправления в систему и сразу же представляет их пользователям для получения от них обратной связи. Часто требуемые изменения могут быть внесены за считанные минуты и сразу же на месте представлены для рассмотрения, если встроенный инструментарий архитектурного проектирования (такой, как SalesLogix Architect или Siebel Tools) позволяет это сделать. Таким образом, пользователям предоставляется возможность участвовать в процессе построения системы еще до обучения ее использованию.
Для каждой фазы внедрения, на которой осуществляются доработки системы, проводится тестирование на основе пробных данных в формате и структуре, соответствующих реальным данным. Затем система тестируется при помощи использования копии реальной базы данных. После достижения требуемых параметров целостности и производительности системы в нее вносятся соответствующие доработки, которые затем тестируются на пробных данных, а потом — на копии реальных данных. Только после того как достигается общая целостность системы, она устанавливается для тестирования в существующую бизнес-среду предприятия (параллельно с существующими бизнес-процессами).
Одним из видов сервиса, предоставляемого компаниями-интеграторами, является конвертация существующих данных в новую систему. Многолетняя история работы с клиентами может представлять собой довольно большой массив данных, который вы захотите частично или полностью конвертировать в систему CRM. Чем больше информации должно мигрировать из старых форматов в новую систему, тем дольше может длиться процесс внедрения. В рамках проекта компания-интегратор обычно осуществляет конвертацию всей информации о существующих и потенциальных клиентах, которая имеется в структурированном электронном виде. Эта информация обычно включает как минимум имена клиентов, их адреса, типы, номера телефонов и факсов, ключевые контакты. Если информация недоступна в электронном виде, можно ввести вручную данные о 20% лучших клиентов, которые создают наибольший объем бизнеса для вашей компании. Для этой цели можно использовать временного сотрудника. Информация о других клиентах может быть введена позже, по мере необходимости.
Если информация о клиентах существует в электронном формате, она обычно может быть конвертирована в формат любой CRM-системы. Наиболее удобным форматом файлов для конвертации является "текст, разделенный запятой" (*.csv). Большинство программ для управления контактной информацией — такие, как Microsoft Access, Excel предоставляют данную опцию для экспорта.
Также возможно подключить данные напрямую через таблицы удаленной базы данных, такой как Access, Oracle или Microsoft SQL. В дальнейшем эти связи между таблицами можно использовать для импорта данных.
В процессе конвертации данных вы можете захотеть "подчистить" свои данные о клиентах. Например, старые клиентские записи компаний, с которыми вы больше не работаете. У вас также могут попадаться
Учитывая, что ваша клиентская база данных может сильно отличаться от стандартной, вам может быть интересно запустить различные фильтры, которые могут изменять значения определенных полей для консолидации данных или автоматически вводить пустые поля, такие, например, как "город" в адресе.
В любом случае компании-интегратору потребуется ваша помощь для того, чтобы определить конкретные требования к конвертации данных. Чтобы избежать неприятных сюрпризов на финальных стадиях проекта, необходимо как можно более детально определить требования к конвертации и объемы работ на ранних стадиях проекта.
Если вы хотите, чтобы проект уложился в запланированные сроки, необходимо, чтобы все требуемое оборудование было подготовлено и сконфигурировано до начала разработки и обучения сотрудников. Также необходимо подготовить все рабочее пространство, чтобы потом не терять на это время. В частности, это включает не только подготовку компьютеров на рабочих местах и в серверной, но и проверку кабельной сети, наличие необходимых компонентов. Если предполагается проводить обучение в вашем офисе, необходимо позаботиться о подготовке и оборудовании помещения для проведения обучения.
В широком смысле подготовка рабочего пространства включает следующие основные шаги.
Анализ и оценка существующей конфигурации компьютеров (пригодность для работы системы):
Во время этого этапа происходит установка системы на оборудование заказчика, а также тестирование на предмет целостности и совместимости с существующей инфраструктурой. Перед инсталляцией системы необходимо проверить следующие параметры:
Стандартный набор установки системы SalesLogix может включать, например, следующие компоненты:
Ответственным этапом в процессе внедрения автоматизированной системы является обмен данными с унаследованными информационными системами.
Под термином "унаследованная система" мы подразумеваем информационные системы, которые используются в организации уже значительное время и имеют ограничения по формату взаимодействия или доступа к данным.
До начала проекта мы рекомендуем выписать и кратко характеризовать возможности всех существующих в вашей компании систем автоматизации, с которыми предполагается интеграция. Также необходимо сформулировать потребности в периодическом обмене данными с этими системами (включая периодичность обмена, размер, структуру и описание формата данных). Будет полезно включить контактные имена и номера телефонов сотрудников, которые лучше всего знакомы с каждой из существующих унаследованных систем.
Обучение является неотъемлемой частью любого процесса внедрения. Компании-интеграторы обычно предлагают несколько различных курсов в зависимости от специфики проекта и потребностей вашей команды.
По мере развития вашего проекта внедрения менеджер проекта со стороны интегратора может предоставить конкретные рекомендации о программе обучения на различных стадиях проекта.
Обучение администраторов покрывает вопросы архивации баз данных, управления пользователями, безопасности, добавления новых лицензий, использования механизмов синхронизации данных, поддержки библиотеки документов, управления скриптами.
Техническое обучение по использованию средств архитектурного проектирования является необязательным. Большинство компаний предпочитает обращаться к профессиональным консультантам для внесения изменений в функциональность системы в процессе ее эксплуатации. Если вы хотите лучше понять, как создавать новые отчеты, шаблоны или делать основные изменения в базе данных и формах ввода данных, интегратор предоставит услуги по техническому обучению администраторов баз данных и других сотрудников ИТ, которые будут осуществлять модификации в системе.
Мы считаем, что наиболее эффективным способом обучения технического персонала является тесный контакт с профессиональными консультантами на этапе внедрения системы. Цель технического персонала заказчика в процессе внедрения — накопление опыта для дальнейшей самостоятельной поддержки и развития системы.
Полноценное обучение пользователей — один из наиболее важных факторов успеха проекта. Изменение процессов продаж и маркетинга может оказать огромное влияние на повседневную жизнь компании. Некоторые пользователи могут не принять изменения. Только если конечные пользователи чувствуют себя уверенно в работе с системой, переход на нее произойдет безболезненно.
Любое обучение пользователей включает сочетание домашнего чтения и занятий в классе. Обучение в классе может происходить как на территории центра обучения, так и в офисе заказчика.
Для обучения в офисе заказчика необходимо оборудовать помещение для данных целей, которое должно включать следующее оборудование:
Каждому слушателю понадобится собственный компьютер, соответствующий минимальным требованиям для работы приложений. Мы рекомендуем, чтобы компьютеры слушателей были теми же, что они планируют использовать в дальнейшем для работы в системе. По возможности небольшая локальная сеть может быть использована для обучения.
Иногда имеет смысл перенести обучение пользователей в класс за пределы офиса, чтобы ежедневная работа в офисе не отвлекала сотрудников и не снижала эффективность обучения.
Для того чтобы ваша компания могла эффективно использовать технологии CRM в работе, необходимо наличие двух типов специалистов для дальнейшей поддержки системы — системного аналитика и администратора системы ИТ. От эффективности работы этих сотрудников во многом будет зависеть, сможет ли компания достигнуть поставленных целей в области автоматизации клиентских взаимоотношений.
Системный аналитик отвечает за все вопросы применения системы, т.е. правила доступа к данным, безопасность и разграничение полномочий, процесс ведения клиента. В широком смысле — за любые точки взаимодействия пользователей с данными в системе. Он должен обладать глубокими знаниями сути бизнеса, который ведет ваша компания, включая (но не ограничиваясь этим) продажи, маркетинг и поддержку пользователей. Также эта роль требует знакомства с сотрудниками организации (или департаментами) и их основными функциями. Главной задачей данного специалиста является эффективное применение "бизнес-правил" вашей компании в системе.
Понимание CRM-системы. Требуется хотя бы поверхностное понимание функциональности системы и ее технологических возможностей для того, чтобы принимать взвешенные решения по техническому использованию инструментов системы. Необходимо знание таких понятий, как структура таблиц, безопасность/доступ групп и пользователей, пункты меню, доработка функциональности, процессы синхронизации информации.
Правила доступа к данным и управление процессами. Этот вопрос обычно является наиболее важным, однако он часто упускается из виду. Когда много пользователей начинают работу в системе с одними и теми же данными, необходимо четко регламентировать процесс работы с этими данными. Обычно для этого собирается рабочая группа, которая состоит из представителей конечных пользователей, системного администратора и системного аналитика. Правила, разрабатываемые этой группой, должны включать все аспекты — начиная форматом ввода данных в поля форм и кончая определением процессов продаж и единого формата наименований потенциальных сделок; от решения о том, как формируется маркетинговый источник, до координации обмена данными с унаследованными системами. Однако эти правила должны быть введены в действие, постоянно отслеживаться и совершенствоваться по запросам бизнеса. Системный аналитик должен быть очень хорошо знаком с практикой ведения бизнеса в вашей компании для того, чтобы разрабатываемые им модели использования си стемы подходили к требованиям бизнеса.
Планирование задач. Системный аналитик также будет отвечать за планирование и расписание задач по проекту таким образом, чтобы не возникало конфликтов по срокам, например, чтобы плановая
Актуализация пользовательской документации и программы обучения пользователей. Другим важным аспектом использования системы является постоянная актуализация пользовательской документации и программы обучения пользователей, документирование всех важных функций и правил работы с данными, связанных с использованием "вашей" системы. За счет поддержки актуальной документации и программы обучения все новые пользователи системы смогут добиться продуктивности значительно быстрее.
Администратор системы ИТ отвечает за все технические аспекты работы и поддержки системы и ее конечных пользователей. Этот сотрудник обычно внедряет решения, принятые системным аналитиком, но также и помогает ему лучше понять технические ограничения этих решений.
Понимание технологий системы. Глубокое понимание системы на уровне технологий работы — обязательное требование для внесения изменений, управления пользователями и данными. Этот сотрудник должен посетить необходимые курсы обучения для администратора системы.
Реляционные базы данных и SQL-запросы. Базовые необходимые знания о том, как работает SQL-сервер или Oracle, в зависимости от используемой платформы, а также как строятся SQL-запросы. Также требуется понимание следующих понятий:
Операционная система на рабочих местах (Windows 95/98 или 2000) — минимальное необходимое понимание принципов работы операционной системы, ее архитектуры и принципов взаимодействия между операционной системой и системой CRM.
Отчеты — навыки построения отчетов в соответствии с вашими корпоративными стандартами и умение применить эти навыки для решения аналитических потребностей компании.
Web — понимание основных Web-технологий (HTML /
Ежедневные обязанности администратора системы ИТ могут включать.
| Управление пользователями, группами и уровнями доступа к информации. Создание и актуализация БД для удаленных пользователей. Управление дополнительными модулями. Создание отчетов. Управление импортом/экспортом данных. Контроль активности удаленных пользователей. Мониторинг пользовательской активности |
Установка и модификация ПО. Решение проблем с операционной системой. Администрирование Решение проблем с синхронизацией Резервное копирование и поддержка БД. Установка и настройка баз данных. Мониторинг системы и дискового пространства |
По статистике, около 70% всех проектов в сфере корпоративной автоматизации заканчиваются неудачами (заказчик не достигает поставленных целей). Почему так происходит? Перефразируя классика, можно сказать: "Все успешные проекты успешны одинаково, все неудачные — неудачны по-своему".
Как мы уже неоднократно отмечали, автоматизация процессов взаимоотношений с клиентами — это не столько внедрение конкретного программного решения, сколько бизнес-стратегия, обучение и мотивация конечных пользователей. Подобная работа часто связана с ломкой существующих устоев, борьбой со стереотипами и предрассудками.
Критические факторы успеха использования систем CRM закладываются еще на стадиях разработки бизнес-требований к системе и ее внедрению. Если руководство компании принимает решение о переходе на подобный инструмент управления отношениями с клиентами, оно должно обеспечить не только технологическую базу, но и выработать четкие бизнес-цели и организационные процедуры/регламенты использования системы. Ошибочно полагать, что система является самодостаточной и по мановению волшебной палочки решит все проблемы в области продаж, маркетинга и обслуживания клиентов.
Тем не менее можно выделить несколько основных причин неудач проектов — в сфере CRM в первую очередь (хотя многие из данных причин характерны и для других проектов автоматизации).
Среди наиболее частых причин неудач можно выделить следующие (расположены в порядке убывания приоритета):
Ниже мы рассмотрим более подробно каждую из указанных причин.
Разница между "стратегией" и "системой" CRM заключена в пользователе, который сидит за интерфейсом системы. От него зависит, смогут ли трансформироваться данные и процессы, заложенные в систему, в конкретные преимущества для бизнеса. Несмотря на то что преимущества внедрения системы для компании в целом могут быть очевидны для руководства, это совершенно не означает, что каждый конкретный пользователь на своем рабочем месте также осознает важность и необходимость использования системы.
Учитывая, что система помимо всего прочего является мощным контрольным механизмом, позволяющим количественно оценить эффективность работы каждого конкретного сотрудника во взаимодействии с клиентами, многие сотрудники воспринимают подобную инновацию "в штыки". Иногда приходится даже говорить о целевом саботаже использования системы со стороны сотрудников отдела продаж и маркетинга, не желающих испытывать дополнительное давление и надзор со стороны "бездушного компьютера".
Единого рецепта борьбы с этой проблемой не существует, так как в каждом конкретном случае он зависит от целого ряда факторов, например:
Тем не менее практически всегда преодоление нежелания сотрудников строится по принципу "кнута и пряника", где в качестве "кнута" могут выступать такие требования.
В качестве "пряника" в свою очередь могут выступать:
В целом необходимо отметить, что сотрудники, непосредственно работающие с системой, являются скорее сторонниками, нежели противниками руководства компаний в стратегии CRM. Их система мотивации должна строиться больше методом "пряника". Функции контроля должны быть разумными и справедливыми, в этом случае проблем с использованием системы можно избежать.
Есть варианты объединения возможностей и "кнута", и "пряника" в рамках единого метода, например:
"Постоянное и активное использование системы в рамках регламента, установленного в отделе, автоматически предполагает получение сотрудником дополнительной премии в размере $50 в месяц.
Нарушение регламента или отказ от использования системы в предусмотренном регламентом объеме автоматически предполагает штраф в размере $100 в месяц".
Отдельно необходимо упомянуть о нежелании сотрудников пользоваться системой, вызванном примитивным незнанием ее функций и страхом перед новым технологическим инструментом.
Ряд простых, но действенных мер поможет раз и навсегда решить эту проблему:
Как мы уже отмечали выше, несоответствие ожиданиям является одной из наиболее серьезных проблем любого проекта автоматизации, тем более в сфере CRM.
Красивая и яркая презентация возможностей CRM, получение всех запрашиваемых на проект ресурсов и полномочий в результате может привести скорее к негативному результату, если успехи проекта, пусть даже вполне весомые, не будут соответствовать тому пониманию, которое сложилось изначально в умах руководителей предприятия. "Это все, конечно, хорошо. Но вы же говорили, что после внедрения системы продажи могут вырасти на 300%, а они выросли только на 50%. Правильно ли будет и дальше финансировать этот проект?" — такой ответ ошарашит руководителя проекта, но будет вполне закономерным, если не побеспокоиться об управлении ожиданиями с самого начала реализации проекта.
Бюрократия и формализм — главные союзники менеджера проекта в преодолении данной проблемы. Правильным ответом на провокационный вопрос руководителя в этом случае будет: "Если вы заметили, в финансовой модели, которую мы совместно утвердили, рост продаж в 300% предполагается только в случае наличия дополнительного финансирования, которое вы на прошлой встрече посчитали рисковым. Возможно теперь, когда вы видите успехи нашего проекта, вы подтвердите данный бюджет".
Существует большое количество различных подходов, которые можно использовать для управления ожиданиями заинтересованных сторон и, соответственно, их однозначной трактовки в случае несоответствия ожиданиям. Один из подходов, принятый в компании McKinsey, приведен на схеме ниже. Суть его заключается в осуществлении трех последовательных шагов:
Кто-то может посчитать этот подход слишком "показушным": концентрируясь на "быстрых победах", можно потерять из виду долгосрочные стратегические приоритеты. Однако обширная практика множества компаний показывает, что данный подход всегда приносит максимальную отдачу с точки зрения управления ожиданиями, а время, потраченное участниками проектной команды на формирование и систематизацию целей, рычагов, показателей эффективности, с лихвой компенсируется устойчивым развитием проекта в целом.
Не один проект CRM закончил свой век на архивной полке "Полные провалы" по одной простой причине: руководители предприятия, в целом заинтересованные в успехе проекта, тем не менее не уделяли ему достойного уровня внимания, а ответственные специалисты не обладали необходимым авторитетом или полномочиями для решения ключевых стратегических задач.
К сожалению, часто невозможность решения этой проблемы связана с менталитетом высших руководителей компании. На встречах с собственниками и высшими руководителями крупных и вполне успешных компаний на вопрос: "Как нам стать более клиенто-ориентированными?" хочется ответить: "Начните с увольнения себя и найма более квалифицированного руководителяѕ". Хороший собственник, предприниматель, талантливый производственный руководитель тем не менее, не всегда может управлять процессами взаимодействия с клиентами, часто не хочет принимать новые правила игры в конкуренцию. В этом случае требовать подобных кардинальных изменений от его подчиненных также не приходится.
Но даже когда руководитель сам понимает ценность и важность внедрения стратегии CRM, он зачастую разрывается между несколькими задачами с не менее высоким приоритетом и не может уделять достаточно внимания операционным вопросам.
Учитывая большой объем организационных и структурных изменений, с которыми связан любой проект CRM, в нем не обойтись без такой роли, как
Для увеличения эффективности взаимодействия со
Определяется круг стратегических вопросов, по которым требуется вмешательство спонсора проекта. Этот круг должен быть достаточно небольшим, однако спонсор должен предоставить гарантии того, что по каждому из этих вопросов он сможет найти время для их решения. Если решение не требует эскалации, менеджер проекта должен иметь возможность решить его без привлечения высшего руководства. Например, использование проектного бюджета в оговоренных рамках не должно требовать дополнительной санкции директора, однако любые изменения в смете должны быть немедленно представлены спонсору с подробным объяснением.
Мечта любого руководителя — постоянно иметь на своем рабочем столе "пульт управления" бизнесом с несколькими индикаторами. Если все идет хорошо по тому или иному направлению, индикатор горит зеленым цветом и можно не беспокоиться. Если загорается желтый или красный свет, необходимо вмешаться.
Если отчетность по проекту организована таким образом, что
С другой стороны, в вопросах надзора со стороны высшего руководства действует принцип "У семи нянек дитя без глазу". Слишком много внимания и надзора может быть также губительно для проекта, как и полное их отсутствие.
"Пока гром не грянет, мужик не перекрестится". Запуск CRM-проекта — серьезный шаг для руководства компании. И для того чтобы на него решиться, часто необходимо, чтобы объем накопившихся проблем и задач достиг определенного критического порога.
Соответственно, решившись на реализацию проекта, руководство компании часто пытается "заодно" решить целый ворох смежных или связанных задач, которые существенно увеличивают сложность, продолжительность и риски проекта.
На схеме ниже приведена статистика зависимости отдачи проекта от его сложности (продолжительности). Как видно, существует устойчивая обратная зависимость, т.е. чем сложнее (длиннее) проект, тем выше вероятность того, что он не достигнет поставленных результатов, будет отложен или вовсе остановлен (что обычно говорит о полном провале проекта).
Для того чтобы избежать этой проблемы, необходимо четко делить проект на непродолжительные последовательные стадии (от двух недель до трех месяцев каждая). По каждой стадии необходимо четко определять цели, рычаги и показатели эффективности, причем начинать надо с реализации наиболее понятных, простых и очевидных задач. Более сложные, неопределенные, конфликтные задачи — откладывать на последующие стадии с целью их лучшей проработки и формализации по мере реализации более простых.
От менеджера CRM-проекта часто требуется не столько знание технологий и методологий, сколько политики и психологии. В сложной иерархии крупной компании от правильной расстановки сил зависит успех любого проекта, тем более в сфере
Как минимум любой проект CRM затрагивает три разных подразделения:
Перекос в сторону интересов одного из данных подразделений может стать существенным фактором риска всего проекта. А представьте, если в проекте участвует более трех управлений? Например, если в компании существует несколько отделов продаж — для каждого типа продукции или услуг, причем у каждого свой набор приоритетов и потребностей...
Стоимость владения является одним из тех факторов, который постоянно упускается из виду при реализации различных стратегических и ИТ-проектов. Опыт реализованных проектов показывает, что исходная цена решения составляет только 20–30% от общей стоимости владения. После запуска системы часто и начинаются основные расходы, на которые средства уже не заложены: поддержка и модернизация, обучение персонала, интеграция.
При оценке экономической эффективности проекта необходимо учитывать все возможные "скрытые расходы", связанные с дальнейшим обслуживанием и развитием проекта.
Можно использовать простую таблицу бюджетирования расходов по основным категориям на 3–5 лет (пример приведен ниже) или принятую в вашей компании процедуру.
| Бюджет | |||
| 1 год | 2 год | 3 год | |
| Оборудование и ПО | |||
| Лицензионное ПО системы CRM | |||
| СУБД | |||
| Оборудование и системное ПО | |||
| Услуги | |||
| Консалтинг и написание ТЗ | |||
| Услуги по внедрению | |||
| Услуги по технической поддержке | |||
| Системная интеграция | |||
| Резерв | |||
| Обучение | |||
| Обучение конечных пользователей | |||
| Обучение технического администратора | |||
| Внутренние ресурсы | |||
| Менеджер проекта | |||
| Бизнес-аналитик | |||
| Системный администратор | |||
| Накладные расходы | |||
| Транспортные расходы (командировки) | |||
| Представительские расходы | |||
| Общий итог | |||
Как мы уже неоднократно отмечали, стратегия CRM не имеет смысла без использования возможностей информационных технологий. Однако это вовсе не означает, что заниматься проектом должны специалисты отдела ИТ.
В нашей практике можно вспомнить лишь несколько проектов, где лидерами проекта внедрения CRM-системы выступали ИТ-специалисты, причем все они сталкивались с одними и теми же проблемами, уже описанными выше. Отсутствие внутреннего спроса со стороны руководителей бизнес-подразделений или чрезмерное увлечение технологическими "наворотами" современных систем заводили подобные проекты в тупик.
Тем не менее руководители компаний продолжают с завидным постоянством направлять любые проекты, связанные с автоматизацией, в ведение ИТ-отдела, тем самым существенно увеличивая риск провала.
Всех этих ошибок можно избежать и снизить риск неудачи при внедрении и использовании системы. Аккуратными, поступательными движениями, избегая методов "взрыва бомбы" или решений "под ключ", можно приучить пользователей к новой культуре эффективной работы с клиентами и использованию соответствующих технологических средств.
70% всех проектов в области автоматизации заканчиваются неудачами! Это слишком высокий показатель для того, чтобы пускать данные проблемы на самотек. Тем более что изобретать велосипед здесь не нужно — многолетний опыт тысяч компаний уже собран в методиках, рекомендациях и технологических решениях. Нужно только уметь их правильно использовать.
Общие рекомендации для тех, кто хочет попасть в счастливые 30% удачных проектов:
Ставить реальные исполнимые цели, не соглашаться на невыполнимые сроки, требовать необходимых полномочий и ресурсов, опираться на четко сформулированные показатели эффективности.
Поставщики решений будут постоянно придумывать новые "большие идеи" и стратегические концепции, призванные увеличить добавленную стоимость предлагаемых программных и технологических решений. Они будут использовать красивые термины для того, чтобы красивее представить обыденные рабочие инструменты. Опирайтесь на функциональные требования и бизнес-приоритеты, а не на концепции при выборе и внедрении решений.
В конечном итоге любой проект автоматизации — это венчурный инвестиционный проект. Используйте раздел "Язык денег" в конце данной главы для того, чтобы лучше понимать терминологию финансовых менеджеров, и оперируйте ею при обосновании проекта и его реализации.
Основной задачей данного раздела является подготовка вашей компании к внедрению у себя системы CRM с участием профессиональной
В основе раздела лежит методология внедрения информационных систем компании Sputnik Labs, адаптировавшая опыт крупнейших мировых производителей прикладного программного обеспечения для автоматизации среднего бизнеса (предприятия с количеством сотрудников от 20 до 2000) к условиям российской действительности.
Здесь вы найдете базовую информацию по организации своего проекта внедрения, включая утверждение структуры команды, планирование и отчетность по проекту, план внедрения, а также краткое описание существующей проектной
Отдельный раздел посвящен подготовке вашей проектной команды к непосредственному запуску проекта (т.н. "Project Kick-off"). Этот раздел объясняет важность правильного анализа бизнес-потребностей и их формализации. Здесь же даются рекомендации, как лучше подготовить информацию по бизнес-процессам, чтобы сделать запуск проекта наиболее эффективным.
Мы также включили раздел про обучение для участников вашей команды внедрения, которое будет проходить, начиная с момента запуска проекта, а также в процессе дизайна и внедрения системы, а также после ее окончательного развертывания.
Мы уверены, что, следуя описанным здесь рекомендациям, вы сможете хорошо подготовиться к проекту внедрения системы и извлечь максимальную пользу из вложенных в него ресурсов.
Чтобы не путаться в терминах, мы предлагаем использовать следующие основные определения:
| Заказчик | Компания, внедряющая у себя решение CRM сопривлечением внешних профессиональных консультантов. Данное руководство ориентировано в первую очередь на руководителей проекта внедрения в подобных компаниях |
| Подрядчик | Компания — поставщик профессиональных услуг в области внедрения систем CRM, такая как Sputnik Labs |
Что мы вкладываем в понятие "защита проекта"? Любое начинание в компании сталкивается с противодействием. В нашем случае CRM-проект может столкнуться с большим количеством различных тормозящих факторов: непониманием и невниманием со стороны руководства, апатией или даже саботажем со стороны конечных пользователей, консерватизмом ИТ-специалистов, ограничениями корпоративных стандартов, нежеланием партнеров раскрывать информацию и многими другими.
Далее мы рассмотрим большинство из препятствий, возникающих обычно при внедрении CRM, и дадим советы о путях их преодоления. Любой проект, предполагающий не просто внедрение программного инструментария, а изменение всей стратегии и методов ведения бизнеса в компании, требует детальной проработки и подготовки к обстоятельной защите.
Необходимыми базовыми условиями развития стратегии CRM являются как минимум следующие.
Суть самого процесса защиты проекта в этом случае сводится к необходимости убедить руководство, коллег, возможно, акционеров в важности данного проекта, сформировать бюджет, определить стратегию реализации, потенциальных партнеров и поставщиков, выбрать технологический вариант решения.
В России катастрофически не хватает опыта реализации проектов в области CRM — как внутри компаний, так и у поставщиков технологических решений и бизнес-консультантов. Это приводит к тому, что неумелая или некорректная аргументация при защите проекта приводит к несоответствию ожиданий и бьет по интересам компании, репутации менеджера и поставщика услуг. В результате теряют все.
Основной задачей на данном этапе, как для
На ежегодном "съезде" всех партнеров одного из крупнейших производителей CRM-систем в мире представители данного производителя представляли новую версию технологической платформы.
В ряду планируемых изменений в структуре новой версии системы они предложили убрать из системы модуль прогнозирования, предоставляющий возможности построения красивых, но малопрактичных графиков и таблиц. "По данным опросов наших существующих клиентов, менее 10% из них пользуются функциями этого модуля. Тем, кому действительно нужны возможности прогнозирования, используют для этого встраиваемые модули сторонних производителей, — говорил в своем докладе директор по производству новых версий. — При этом разработка и поддержание этого модуля отнимает у нас существенные производственные ресурсы".
Подобное решение вызвало негативную реакцию среди партнеров, осуществляющих продажу и внедрение системы по всему миру. "С одной стороны, — говорили многие из них в кулуарах, — производитель прав. Никто практически не пользуется данным модулем. Однако его наличие [красивые яркие графики, которые динамически изменяются в соответствии с текущим состоянием] является просто необходимым при демонстрации системы высшим руководителям! Они влюбляются в него и готовы платить больше, хотя никогда в дальнейшем даже не вспомнят про этот модуль..."
Приведенный пример показывает, что ожидания руководителей предприятия при запуске проекта и реальные потребности бизнеса могут существенно различаться. Необходимо правильно подобрать критерии, представить и обосновать их на ранних этапах проекта.
В чем же все-таки заключается сложность грамотной защиты проекта CRM?
Почему мы так детально останавливаемся на этом вопросе именно на этапе защиты проекта? Разве эта работа не является основной задачей привлеченных консультантов или приобретаемой системы? Далее мы постараемся объяснить, почему эти задачи мы относим именно к этапу защиты, а не реализации проекта, и приведем реальные примеры из жизни.
Вы можете потратить несколько лет, доказывая необходимость реализации стратегии CRM в вашей компании и слышать в ответ: "Это очень важно, я понимаю, но сейчас у меня другие приоритеты". Практический опыт показал, что следующие сценарии развития ситуации могут заставить руководителя бизнеса предпринять немедленные шаги в сторону CRM.
| Сценарий | Основной движущий фактор для внедрения | В чем заключается основная потребность руководителя |
|---|---|---|
| Кризисный | Возникновение кризисной ситуации, например: |
Контроль за информацией. Систематизация деятельности сотрудников |
| Развивающий | Бурное развитие бизнеса (или потребность в развитии), которое невозможно осуществлять "по старинке". Может выражаться в следующем: |
Автоматизация рутинных операций. Контроль эффективности. Накопление и передача знаний |
| Статусный | Необходимость CRM определяется внешними факторами, например: |
Реализация условий, налагаемых внешними факторами (руководством, инвесторами и т.д.) |
В разделе "Кому не нужна стратегия CRM?" рассматриваются более подробно причины отказов. Здесь мы лишь приведем таблицу с основными причинами и возможной "домашней работой", которую необходимо проделать, чтобы бороться с каждой из указанных причин.
| Причина | В чем суть проблемы? | Домашняя работа |
|---|---|---|
| Отсутствие внутреннего спроса | Непосредственные бизнеспользователи не заинтересованы в решении задач CRM по тем или иным причинам, отсутствуют бизнес- |
Поиск и убеждение потенциальных бизнесспонсоров на самом высоком уровне. |
| Финансовые ограничения | В бюджете нет средств на CRM, финансовое руководство считает эти расходы неоправданными, предлагаемые решения выходят за рамки финансовых ожиданий | Расчет возврата на инвестиции — ROI (Return on Investment), управление ожиданиями, аналитика по расходам конкурентов на развитие CRM |
| Корпоративные ограничения | Существующие корпоративные стандарты не подразумевают использование CRM или не подходят для существующих задач | Разработка "Аналитической записки", или |
| Боязнь неудачи | Предыдущие внедрения систем, таких как ERP, привели к неудаче и разочарованию руководства в эффективности ИТ при огромных затратах времени и средств | Поиск возможных "быстрых побед" для решения конкретных локальных задач в короткие сроки и "малой кровью" |
| Нежелание принимать ответственность | Руководители/подчиненные не желают принимать решения, которые могут негативно сказаться на их карьере, — из-за этого любые инновационные идеи буксуют | Составление списка решений, "за выбор которых точно не уволят", "заговор" энергичных сотрудников, для которых это — шанс всей жизни |
Почему так важно подготовиться к проекту внедрения до его формального запуска?
Подготовка к проекту внедрения экономит вам средства. Привлекая внешних консультантов для осуществления проекта внедрения системы, вы инвестируете существенные средства в работу профессионалов. Вы должны быть уверены, что эти инвестиции будут использованы наиболее оптимально. Чем больше времени и усилий консультантов будет уходить на непродуктивное ожидание и "выуживание" информации, тем меньше конструктивных бизнес-задач они смогут решить за выделенное на проект время.
Весь успех CRM-проекта зависит от четкого определения и формулировки бизнес-целей. Речь здесь идет не о декларативных лозунгах, что с клиентами нужно быть более обходительными, а о четко сформулированных и решаемых стратегических целях. С обсуждения этих целей начинается (или должен начинаться) любой стратегический проект, так как именно на основании этих целей в дальнейшем поставщики будут предлагать свои варианты решений, а руководство — выделять средства на CRM-проект. Если у основного инициатора проекта нет четкого видения, какие бизнес-проблемы могут быть решены в ходе проекта, того же видения не будет и у руководства, и у поставщиков, и проект будет лишен основной части — смысла ("Зачем мы все это делаем?"). Примеры не четко сформулированных целей: "Повышение эффективности работы отделов продаж, маркетинга, сервиса", "Повышение прозрачности и управляемости бизнеса", "Улучшение взаимодействия между департаментами" — все эти цели неконкретны. Такие формулировки могут присутствовать только если в дальнейшем они будут детализированы и связаны с решением конкретных бизнес-проблем и достижением конкретных целей. Почему мы разделяем понятия "проблемы" и "цели"? Дело в том, что предпринимать какие-либо шаги в направлении CRM-компании побуждает либо недовольство текущим положением вещей и желание что-то поменять в существующей практике (бизнес-проблемы), либо наличие новых стратегический целей, связанных с будущим развитием компании (бизнес-цели). В целом не важно, что именно явилось источником интереса к CRM. В большинстве случаев это сочетание и того и другого.
Сложность выявления бизнес-проблем заключается в том, что часто руководство имеет достаточно абстрактное представление о проблемах собственной компании. Распространена ситуация, когда на вопрос: "Какие проблемы бизнеса побудили вас начать поиск CRM-решения?" приводятся аргументы следующего характера: "Отсутствие единой базы данных клиентов". Само по себе отсутствие единой клиентской базы еще не является проблемой для бизнеса. Реальные проблемы возникают в связи с отсутствием такой БД, но в каждом конкретном случае из-за одной и той же предпосылки возникают совершенно разные проблемы. В одной компании проблема заключается в непродуктивном использовании рабочего времени продавца и росте издержек на клиентское обслуживание в связи с отсутствием эффективной системы передачи информации. В другой проблемой является низкая эффективность маркетинговых мероприятий из-за невозможности сделать узконаправленную выборку клиентов, либо проанализировать предыдущую эффективность мероприятий. И задача инициатора проекта на данном этапе — правильно сориентировать свое руководство и вместе с ним выстроить всю цепочку от предпосылки до определения реальных бизнес-проблем. Общий принцип следующий: любая бизнес-проблема имеет денежное выражение. На чем может терять или не зарабатывать деньги ваша компания, например, из-за отсутствия единой клиентской базы?
Кстати, определенные на данном этапе бизнес-цели и бизнес-проблемы еще никак не связаны с конкретным CRM-продуктом или CRM-системой вообще. Возможно, задачи более эффективно и правильно можно решить определенными организационными и структурными мерами: перестроить систему стимулирования, усилить дисциплину, провести обучение и т.д.
Именно на этом этапе инициатор проекта дает обещания. Как решить конкретную задачу? Будет ли это работать? Что компания сможет изменить в дальнейшем? Часто для достижения поставленных целей не требуется дорогостоящий программный инструментарий или изощренная стратегия — достаточно базовых функций по учету и контролю за информацией, организационной целостности, дисциплины и мотивации. В консалтинговых компаниях существует визуальный алгоритм, позволяющий определить, какие же функции необходимы клиенту. Он называется "
Ниже приведен пример детализации возможной цели до уровня способа решения задачи.
Из рисунка видно, что для решения различных задач могут использоваться одни и те же способы. Чем более универсальными являются те или иные способы, тем выше будет их приоритет реализации в дальнейшем.
Почему важно провести эту работу в укрупненном виде, уже на этапе внутренней продажи проекта? Потому что убедительным для руководства является решение конкретных проблем бизнеса, а не сам факт использования "крутой" или "навороченной" современной системы. Не одно хорошее и благородное начинание разбилось о камень непонимания со стороны руководства, потому что при обосновании проекта для руководства использовались такие понятия, как "самая современная технология", "революция в стандартах", "требования рынка".
Также на этом предварительном этапе происходит оценка трудозатрат по проекту и появляется представление о том, что может быть реализовано и какими средствами. Определив проблемы, задачи и способы решения, а также поняв специфику бизнеса компании, можно предварительно определить перечень конкретных действий и функций и понять, насколько компании "по силам" сейчас браться за решение этих задач. При этом важно: а) представлять возможности и специфику функциональности различных систем; б) знать на примерах других проектов, как данная функциональность может быть применена для решения конкретных бизнес-проблем.
Часто компании, переводя описание своих бизнес-задач и целей в список конкретных методов и функций, попадают в распространенную ловушку: не имея представления о существующих стандартных возможностях систем автоматизации, им сложно правильно расставить приоритеты в автоматизации.
Например, руководство компании в качестве приоритетной задачи выделило необходимость информирования клиентов о важных событиях — ключевых транзакциях по счетам, специальных условиях и скидках, новых интересных для клиента продуктах и т.д. В качестве средств информирования можно использовать звонок менеджера по продажам (в этом случае функция, ответственная за информирование, заключается в автоматическом назначении менеджеру по продажам соответствующей задачи — позвонить клиенту). С другой стороны, можно использовать средства рассылки по электронной почте, SMS, факсу и автоматический обзвон автоинформатором. Сложность реализации каждой из этих функций может существенно превышать экономический эффект от ее внедрения. Не имея представления о трудоемкости и ресурсоемкости каждой из этих функций, оценить целесообразность их использования будет достаточно сложно.
Есть риск, что составленный перечень требований к функциональности может оказаться неприменимым, т.к. не будет ни одной системы, обладающей всеми функциями. Либо формулировка требований будет неконкретной, и под нее можно будет подвести практически любую систему.
Вот пример, иллюстрирующий приведенную выше схему. "Соблюдение технологии продаж" может заключаться в следующем:
При этом один продукт позволяет "прописать" цикл продажи в указанном виде (в виде стадий и шагов). Другой имеет набор инструментов для каждой стадии: специализированные формы и сценарии квалификации клиента, анализа потребностей клиента, возможность задать правила предложения определенных продуктов (если клиент обладает заданным набором характеристик, то при любом контакте клиента с организацией система рекомендует предложить ему тот или иной продукт) и т.п. И соотнесение бизнес-задачи и функций CRM-системы требует знания этих функций.
К сожалению, только реальный опыт дает понимание сложности внедрения той или иной функциональности под специфические потребности бизнеса. А, следовательно, уже на данном этапе опытный консультант может скорректировать ожидания компании и правильно сориентировать ее руководителей, выявив те задачи, которые при минимальных затратах позволяют достичь максимального эффекта.
Таким образом, при грамотном подходе к защите проекта у его инициатора должно быть четкое, согласованное видение того, какие проблемы планирует решить компания, какие функции для этого необходимы, какие дополнительные работы придется совершить и какие затраты времени и средств для этого понадобятся. Вся эта информация должна войти в обоснование проекта. Рамки проекта на данном этапе должны быть максимально конкретными и целенаправленными.
Все поставщики решений и консалтинговые компании с радостью предложат осуществить работы по определению и детализации бизнес-проблем и целей. Соответствующая услуга, которая может называться "предпроектное обследование", "постановка задачи", "разработка технико-экономического обоснования", входит в перечень возможностей любого CRM-поставщика. Тем не менее полностью доверять сторонним консультантам в этих вопросах нельзя. "Независимые" консультанты (т.е. компании, не предоставляющие услуги по внедрению конкретных систем) в своих оценках будут так же оторваны от реальных возможностей современных систем, как и вы сами. "Зависимые" консультанты будут ориентироваться в первую очередь на возможности собственных продвигаемых систем автоматизации.
Любой проект в области ИТ — это всегда компромисс между несколькими противоречивыми интересами, такими как:
Помните басню про жадного купца, который пытался сшить побольше шапок из одной овчинки? В результате он выторговал семь шапок, но каждая из них получилась настолько маленькой, что не налезала на голову.
Та же ситуация наблюдается, когда руководитель предприятия ставит перед проектной командой задачу по принципу: "Нам нужна максимальная функциональность про запас за минимальные деньги! Да, и она нужна нам вчера". Результатом будет пропорциональное увеличение рисков проекта, и весь экономический эффект от внедрения может быть поставлен под удар.
Очевидно, что попытка достичь максимума по каждому из приоритетов одновременно равносильна попытке сшить как можно больше шапок из одной овчинкиѕ Управление проектом — это умение постоянно балансировать между существующими интересами, чтобы каждый получил заслуженный приоритет, сохраняя при этом устойчивое равновесие.
Умение соблюсти баланс этих интересов — основной навык, необходимый руководителю проекта внедрения CRM для обеспечения своего личного и корпоративного успеха.
Многие компании экономят каждую копейку на закупках различной техники и расходных материалов, однако проявляют неосведомленность в процессе выбора информационных систем, таких как CRM. А принятие решения по закупке автоматизированной системы на основании поверхностного изучения нескольких рекламных буклетов и пары маркетинговых презентаций может дорого обойтись.
На рынке предлагаются сотни систем, название которых содержит модную аббревиатуру "CRM", однако комплексное "построчное" сравнение функциональных и технических особенностей всех возможных вариантов может отнять годы работы лучших сотрудников. Даже коммерческие исследования с независимым описанием и сравнением существующих решений не проясняют ситуацию.
Побывав "по обе стороны баррикад", мы предлагаем простую, но действенную методологию для отсева "мишуры" и выбора нескольких возможных систем, в нюансы которых уже имеет смысл вникнуть более подробно. Это позволит сэкономить время как ответственным сотрудникам, так и потенциальным поставщикам.
Первый шаг в выборе поставщика любой информационной системы — составление так называемого "короткого списка" претендентов (не более 2–3 систем), которые уже могут участвовать в тендере. Выбор окончательной системы по результатам тендера всегда является прерогативой высшего руководства, часто представляет собой в большей степени политический, нежели экономический процесс и может базироваться на субъективных факторах. В данной статье мы не рассматриваем факторы, влияющие на окончательный выбор системы. Задачу, которую обычно ставит руководство компании перед будущим руководителем проекта, можно сформулировать следующим образом: "Вы нам представьте список из 2–3 вариантов решений, каждое из которых подойдет нам по требованиям. А мы уже выберем лучшего среди равных". Таким образом, каким бы нелогичным и субъективным ни было решение руководства о выборе той или иной системы, оно не станет причиной неуспеха всего проекта.
Западные эксперты считают, что особое значение для экономии времени и сил имеет процесс рассмотрения первичных предложений и ознакомительных презентаций. Чтобы этот процесс сразу направить в правильное русло, в первую очередь необходимо определиться с собственными ожиданиями: какие ключевые задачи вновь приобретаемая система должна будет решать?
При выборе нужно отдавать предпочтение системам, которые помогут быстрее и эффективнее достичь ожидаемых целей, при этом стараясь меньше отвлекаться на всевозможные "спецэффекты".
| Методология быстрого отсева поставщиков CRM-систем | |
|---|---|
| Инструкция для формалиста | Какие документы нужно использовать? |
| Сформулируйте для себя: См. раздел "Знайте свои цели" или "Пример списка квалификационных вопросов" |
"Служебная записка" (для внутреннего использования) для всех участников процесса отбора, регламентирующая процесс выбора. Обязательна подпись ответственного руководителя. "Список квалификационных вопросов" (для внешнего использования). Рассылается всем заинтересованным поставщикам на любые вопросы, связанные с проектом. "Один день из жизни". Сценарий (или несколько сценариев), описывающий "человеческим языком" требования пользователей к системе. |
| Проанализируйте полученные от поставщиков заполненные анкеты "Список квалификационных вопросов" Сформулируйте ответы на вопросы: Отбросьте явных "аутсайдеров". Пошлите им письмо с благодарностью за участие (хорошие отношения с поставщиками пригодятся в будущем!) |
Ревизия "Служебной записки", если необходимо. Таблица соответствия требованиям. Простая таблица, в которой можно отметить плюсы и минусы по наиболее важным параметрам для всех предлагаемых систем. Письмо "Благодарность — отказ" |
| Выслушайте презентации/демонстрации поставщиков: |
Наброски "Технического задания", чтобы умные мысли записывать туда по горячим следам. Альбом для рисования каракуль, чтобы выдержать многочисленные скучные презентации об одном и том же |
| Составьте "короткий список" решений по результатам презентаций: См. раздел "Отбираем кандидатов" |
Детальные наброски "Технического задания" (именно наброски, потому что полноценное ТЗ можно будет составить только после выбора поставщика, и только совместно с ним). Письмо "Благодарность — отказ" |
| Рассмотрите |
Дополнительные инструменты поставщиков (например, бесплатная демонстрационная версия системы или результаты бесплатного экспресс-анализа бизнес-процессов), если они их предлагают. Докладная записка руководству с обобщением результатов выбора и рекомендациями (желательно скрепить подписями других членов команды и заинтересованных пользователей во избежание обвинений в предвзятости) |
| Минимизируйте ущерб от субъективизма руководства: |
"Служебная записка" (для внутреннего использования) из пункта 1. Докладная записка для руководства из пункта 5. Зловещее (для поставщиков) письмо "Благодарность — отказ". Письмо выигравшему поставщику с указанием условий и плана дальнейших действий |
Исследования в США и Европе показали, что неспособность сформулировать конкретные ожидания остается главной причиной провала стратегических инициатив в области CRM. Даже в условиях экономической стагнации и жесткой экономии в списке причин задержек при внедрении "Прекращение финансирования" стоит после пункта "Отсутствие четкой стратегии".
Решение этой проблемы начинается в процессе первичного отбора возможных систем. В запросе на предложения необходимо сразу постараться сформулировать основные критерии оценки эффективности проекта — такие, как увеличение продуктивности работы (насколько?) и возврат на инвестиции (в каком объеме?). Вы можете спросить поставщиков, как они могут помочь в соблюдении этих критериев, а также попросить рекомендации клиентов, которые использовали эти системы для достижения похожих целей. Это возымеет значительно больший эффект, чем выбор системы на основе списка функциональности.
Как это ни странно, сформулировать практичные и достижимые цели проекта в большинстве случаев бывает довольно сложно, особенно когда речь идет об автоматизации "с нуля". Записав две-три избитые фразы типа "Увеличить объем продаж" или "Оптимизировать процесс прохождения сервисных заявок", менеджер часто впадает в глубокое раздумье: а в какой мере информационная система действительно сможет обеспечить такие результаты? Как определить, действительно ли увеличение продаж произошло благодаря внедрению системы, или просто имело место сезонное колебание?
Выше мы уже останавливались коротко на методологии определения бизнес-целей. Ниже мы также более подробно остановимся на процессе формализации и анализе бизнес-требований, который призван превратить список целей и бизнес-проблем в конкретные формальные требования по проекту. Насколько глубоко вы собираетесь самостоятельно пройти от определения целей и проблем до формализации конкретных функциональных требований прежде, чем обратитесь к поставщикам, а какую часть работы переложите на них уже после подписания договора, — решать вам.
Для того чтобы сократить число возможных систем до трех (оптимальное число для участия в комплексном тендере), можно обратиться за помощью к специализированным консультантам или исследовательским агентствам. Многие из этих компаний собирают информацию о существующих продуктах и постоянно отслеживают все изменения и достижения в данной предметной области. Поэтому они могут помочь более объективно сравнить функциональность и ценовые характеристики различных систем.
Многие компании уже пользуются услугами подобных консалтинговых компаний или исследовательских агентств в других областях, однако мало кто прибегает к их услугам для квалифицированного отбора технологических решений. Участие внешнего консультанта на первом этапе отбора решений-кандидатов позволит не только сократить время на процесс отсева, но и обеспечит непредвзятую
Вы будете удивлены, узнав, сколько ИТ-компаний в России специализируется на предоставлении подобных услуг, причем делают они это на достаточно высоком уровне и за приемлемые деньги (средняя цена подобных услуг в Москве составляет 3–10% от предполагаемого бюджета внедрения системы в зависимости от роли и меры ответственности внешнего консультанта).
Если все-таки вам трудно ограничить список кандидатов, не поленитесь связаться с компаниями — клиентами потенциальных поставщиков и поинтересуйтесь их мнением. В большинстве случаев, если вы ничего не продаете и не являетесь прямым конкурентом, менеджер другой компании с удовольствием расскажет все, что он об этом думает.
Пожалуй, наиболее эффективный путь отбора кандидатов — рассылка списка обязательной функциональности предлагаемой системы с запросом квалифицированного ответа. Такую рассылку можно легко и быстро сделать по электронной почте и не утруждать ни себя, ни других презентацией функций, которые вам не нужны.
Можно, например, подготовить список из 15 вопросов, каждый из которых будет посвящен определенной проблеме, с которой предполагаемая система должна справиться. Далее этот список можно разослать максимальному числу претендентов. Задавать более 15 вопросов не имеет смысла, потому что большинство компаний не будет тратить время на то, чтобы на все из них обстоятельно ответить, менее 10 вопросов не позволит квалифицированно определить различия предлагаемых систем.
Возможно, для составления короткого списка вопросов вам потребуется участие всей команды, включая руководителей, технических специалистов и конечных пользователей, — чтобы вопросы были разноплановыми и максимально точными.
Если вы спросите, можно ли управлять продажами через предлагаемую систему, то, скорее всего, получите развернутый ответ, не имеющий конкретной экономической пользы, например: "Наша система обладает всеобъемлющей функциональностью в области управления продажами". Если же вы сформулируете свой вопрос иначе, указывая конкретные требования, например: "Секретарь принимает звонок и вводит данные в систему. Далее система должна выбрать менеджера по работе с этим клиентом и поставить ему задачу связаться с клиентом и выяснить детали в заданный срок. Возможно ли это? Требуется ли дополнительное программирование для реализации этой функции?", то поставите поставщика перед необходимостью четко раскрыть ограничения системы: "Реализация данной функции потребует определенных дополнительных настроек, однако успешный опыт использования аналогичного решения существует в компании N".
Ключевым фактором успеха для покупателя является понимание того, что он ожидает увидеть в качестве ответов поставщиков. Большинство продавцов будут отвечать то, что, по их мнению, должно понравится покупателю, или будут слишком пространны в своих ответах, обходя существующие ограничения системы, если формат запроса позволяет это сделать. Составление списка вопросов, которые могут дать представление о возможностях системы и ее поставщика, и при этом не дают простора для того, чтобы вешать лапшу на уши, — большое искусство, требующее определенных навыков и сноровки.
Чтобы помочь вам в этом процессе, мы подготовили пример, который может дать начальную почву для размышлений. При закупке небольших систем (например, на 5–10 рабочих мест) его можно использовать в качестве формального "Запроса на предложения" (
| Пример списка квалификационных вопросов |
|---|
Компания N рассматривает возможность приобретения CRM-системы для снижения издержек на операционное обслуживание клиентов и увеличения объемов кросс-продаж между различными подразделениями холдинга. Мы планируем автоматизировать до 30 рабочих мест в течение первого года работы, включая отдел маркетинга (5 чел.), отдел продаж (10 чел.), отдел поддержки (10 чел.) и административные службы (бухгалтерия, руководство, ИТ — всего до 5 чел.) Наша компания заинтересована в долгосрочных отношениях с профессиональным поставщиком систем, отвечающим нашим требованиям для осуществления комплексного внедрения, обучения и технической поддержки данного решения. Мы предполагаем провести выбор поставщика в течение 4-х недель с момента рассылки данного запроса и ожидаем, что процесс внедрения будет осуществлен в течение 3-х месяцев с момента выбора поставщика. Пожалуйста, ответьте на предложенные ниже вопросы, чтобы мы могли лучше понять возможности предлагаемых вами решений. Детальные требования и технические спецификации будут предоставлены только компаниям, прошедшим первичную квалификацию (после подписания соглашения о конфиденциальности). |
Поставщики, которые действительно заинтересованы в вас как клиенте, представят развернутый ответ в кратчайшие сроки. Подобный подход позволяет сузить круг потенциальных решений с десятков до единиц. Практический опыт показывает, что составление квалифицированного списка вопросов и правильная обработка результатов позволяет просеять 30–40 поставщиков и выбрать из них 3–4 в течение недели.
Когда количество поставщиков, составляющих "короткий список", не превышает 3–4, с ними можно организовать более тесное и конструктивное взаимодействие. В частности, можно подписать Соглашение о конфиденциальности, разослать технические спецификации и бизнес-требования, а также расширенный список квалификационных вопросов, который иногда может включать до 100 пунктов.
Примерный список критериев выбора решения CRM
Вот список критериев, которые наиболее часто используют компании при выборе решений CRM (в скобках указан весовой коэффициент данного параметра, %).
Соответствие запрашиваемой функциональности (50%) Составить полный список необходимых функций с указанием приоритетов (или этапов) и сложности реализации — shopping list.
Попросить поставщиков указать, какие из функций входят в базовую функциональность, какие требуют доработки.
Сделать сквозной анализ каждой функции.
Цена решения (30%) Разброс цен может быть огромным — от $5000 до $500 000 за один и тот же набор функциональности.
С поставщиками можно и нужно торговаться.
Общая стоимость владения (10%) Исходная цена решения — только 20–30% от общей стоимости владения.
Используйте косвенные факторы для оценки ОСВ — стоимость дополнительного рабочего места, обучения, технической поддержки и т.д.
Какие гарантии дает поставщик?
Масштабируемость (5%) Что будет с предлагаемым решением через 2–3 года, когда ваш бизнес вырастет? Какие сценарии предлагает поставщик?
Опыт применения в России (5%) Кто уже использует решение в России, и насколько эффективно? Можно ли организовать визит к существующему клиенту?
Прежде чем вы начнете проект по внедрению системы CRM, консультанты компании-подрядчика должны лучше понять ваш бизнес, процессы, типы данных. Для того чтобы проектная команда получила представление о работе вашей компании, необходимо предоставить ей доступ к соответствующим источникам информации, включая Web-сайт, маркетинговые материалы, внутренние регламенты и процедуры или другие документы по вашей компании и индустрии в целом.
Все требования можно условно разделить на функциональные и нефункциональные. Функциональные требования определяют, что именно система должна уметь делать. Нефункциональные требования связаны с характеристиками системы — такими, как производительность, устойчивость, системные интерфейсы, ограничения по дизайну. Требования также могут включать задачи и цели системы, которые предполагается достигнуть.
Основной целью анализа требований является формализация детальных спецификаций, которые однозначно определяют, что должна представлять собой система после окончания проекта внедрения.
Детальные спецификации — это то, что можно характеризовать следующими параметрами:
Первым этапом формализации требований является их определение. Правильно реализованный процесс определения требований сэкономит огромные ресурсы на последующих этапах разработки программного обеспечения. Всегда проще и эффективнее создать приложение после того, как все требования к нему собраны и описаны, чем делать это в процессе их сбора.
Главная цель процесса определения требований — снабжение проектной команды объективной и целостной информацией для составления плана-графика проекта и функциональных требований к системе.
Основная сложность и ответственность на этапе определения требований заключается в том, что необходимо определить все требования, которые можно считать необходимыми и достаточными.
Условие необходимости подразумевает, что каждое из определенных требований действительно необходимо бизнесу и в список не попали те требования, которые являются излишними.
Условие достаточности подразумевает, что список содержит все необходимые бизнесу требования, ни одно не было забыто. Соблюдение условия достаточности требует от аналитика, составляющего список требований, определенного опыта и практических знаний в данной индустрии. Он должен уметь "предвидеть" вопросы, которые сотрудники компании-заказчика могли упустить из виду или посчитать несущественными из-за отсутствия опыта решения подобных задач.
Так как каждый проект всегда уникален, не существует готовой "книги рецептов" для определения требований. Каждый проект требует собственной стратегии для этого процесса в соответствии со спецификой вашей компании.
Если вы никогда раньше не участвовали в процессе сбора и формализации требований, вам будет трудно четко и однозначно сформулировать задачи автоматизации. Однако существует много источников, которые могут помочь в выполнении этого "домашнего задания". Приведем основные принципы по организации процесса формализации собственных требований.
Следует мысленно разделить процесс определения своих целей на три основных этапа:
Эти три этапа можно разделить на следующие основные шаги.
Избегайте следующих "классических" проблем при анализе потребностей:
Проблемы масштаба можно избежать, если начать анализ потребностей "сверху", двигаясь от общего к частному, определив изначально общие границы и задачи проекта. Следующие факторы при этом являются существенными:
Организационные факторы.
Факторы среды:
Проблема понимания может возникнуть из-за следующих причин:
Требования бизнес-пользователей не всегда могут быть сразу корректно сформулированы еще до начала проекта. Требования к системе, таким образом, будут постоянно меняться в процессе разработки. По мере развития процесса разработки, как пользователи, так и разработчики постоянно приобретают более глубокое понимание проблемы. Дополнительные знания приводят к необходимости добавить новые или изменить существующие требования. Для того чтобы эффективно работать в изменчивой среде потребностей бизнеса, процесс детализации потребностей должен происходить постоянно и итеративно.
Для наших целей бизнес-процессом называется определенная последовательность действий или процедур, которые должны быть осуществлены для выполнения поставленной задачи. Какие-то процессы могут быть формально описаны как четкая последовательность действий в регламенте, следование этому регламенту является обязательным. Другие процессы могут быть неформальными, они могут быть описаны на уровне общих принципов, не обязательных для четкого следования. Некоторые компании полагаются на "принятую мировую практику" того, как должны выполняться те или иные действия — они могут обходиться без письменных регламентов.
Проект внедрения CRM обязательно будет связан с существующими бизнес-процессами в вашей компании. Какие-то из процессов нужно будет создать или перестроить. Консультантам потребуется собрать необходимую информацию для понимания и лучшего планирования ваших бизнес-процессов.
Компания будет лучше подготовлена к запуску проекта внедрения, если вы выполните следующие шаги на этапе определения своих задач и потребностей.
Рассматривая собственные бизнес-процессы, вы можете сформулировать "внутреннее понимание проблем", т.е. попытаться ответить на вопрос: "Что не так?" Например:
| Неправильно | Проект должен гарантировать, что продавец сможет аккуратно подобрать конфигурацию и предоставить заказчику четкую спецификацию для заказа. |
| Правильно | Продавцы не могут аккуратно подобрать конфигурацию, что приводит к неточным спецификациям при заказе |
По мере того как вы формулируете свои задачи и вам становятся понятны корневые проблемы в области бизнес-процессов, можно приступать к поиску путей их решения. Вы можете начать этот процесс еще до запуска проекта, а затем проектная команда со стороны подрядчика сможет дополнить/исправить этот список. Констатация возможного решения не должна описывать задачи программного приложения или какие-либо другие детали; она должна четко определять, как необходимо подходить к решению этой проблемы. Например:
| Неправильно | Создать приложение для продавцов, в котором они смогут выбрать конфигурацию и сформировать правильный заказ. |
| Правильно | Предоставить инструмент для конфигурации заказа в соответствии с существующими правилами |
Не рассчитывайте, что вы сможете с первого раза составить детальный и целостный документ. Однако хорошо выполненное "домашнее задание" существенно повысит ваш авторитет в глазах приходящих консультантов и снизит вероятность того, что вас обманут.
Успех любого проекта зависит от квалификации и опыта определенной команды людей (а также от степени их концентрации на задачах проекта). Все участники команды должны быть заинтересованы в успехе. Они должны иметь возможность полагаться как на свой собственный опыт, так и на возможности других участников команды, чтобы совместно сформировать среду эффективного взаимодействия. Вопросы психологической совместимости могут играть в процессе построения эффективной команды принципиальную роль. Со своей стороны, формируя команду участников того или иного проекта, подрядчик выбирает тех сотрудников, которые могут выступать экспертами в данной отрасли, обладают необходимыми знаниями по функциональности систем CRM, а также способны управлять постоянно изменяющимися запросами.
Со стороны заказчика в команде должны участвовать сотрудники организации, обладающие знаниями своего бизнеса и организационной структуры компании. Они способны принимать ответственные решения, учиться и перенимать профессиональный опыт, а также применять его в повседневной работе для развития своей компании.
Приведенная ниже диаграмма показывает стандартную структуру проектной команды для сложного проекта внедрения. Проект внедрения системы на десяти рабочих местах может и не потребовать такой сложной структуры; однако если речь идет о десятках рабочих мест, все элементы этой структуры становятся ключевыми.
Рассмотрим кратко основные элементы командной структуры проекта.
| Управляющий комитет | Ключевым фактором успеха любого инновационного проекта является поддержка высшего руководства. Однако современный руководитель предприятия не может себе позволить повседневное участие в решении задач проекта. Функция управляющего комитета, в который входят руководители компаний заказчика и подрядчика, заключается в решении кризисных и нестандартных ситуаций, которые не могут быть решены сотрудниками на более низких уровнях управления. Наличие такого комитета и его "точечная" активность позволяет избежать застоя в проекте и "патовых" ситуаций с подрядчиками. Часто говорят, что в управляющий комитет должны войти люди, которые "слишком заняты, чтобы участвовать в проекте, однако слишком важны, чтобы полностью упускать этот проект из виду" |
| Менеджер проекта | Главный элемент любой проектной команды — менеджер проекта, или руководитель этой команды. Это конкретный человек, обладающий опытом и наделенный полномочиями. В большинстве случаев функцию менеджера проекта выполняет профессиональный консультант — сотрудник компании подрядчика. |
| Контроль качества | Этот элемент необязательно будет присутствовать в вашей проектной команде, однако мы настоятельно рекомендуем вводить независимую функцию контроля качества на любом проекте с количеством рабочих мест более 20–30. Менеджер проекта и представители компании-подрядчика в процессе реализации проекта могут упустить из виду какие-то важные функциональные элементы, внешние или внутренние факторы, влияющие на успех проекта в целом. Специалист по контролю качества также может выступать гарантом соответствия предлагаемого решения современным технологическим и бизнес-стандартам. Функцию контроля качества может выполнять отдельный сотрудник подрядчика, не участвующий в ежедневной работе над проектом, или привлеченный внешний эксперт. |
| Поддержка производителя | Если вы планируете внедрение современной инновационной технологии, или выбранное вами решение само по себе уникально для вашей индустрии или региона, имеет смысл заручиться поддержкой производителя программного обеспечения. Такая поддержка сможет гарантировать максимально быстрое решение возникающих технических и организационных проблем. В отдельных случаях (в первую очередь, когда проект подразумевает внедрение от 100 рабочих мест) производитель может выслать своего специалиста непосредственно к вам на проект. Однако накладные расходы, связанные с его проживанием и работой, скорее всего, лягут на вашу компанию. |
| Техническая команда Команда бизнес-анализа Системная поддержка и обучение |
В непосредственном подчинении менеджера проекта будут находиться специалисты по решению различных задач — технических, аналитических и поддерживающих. По мере изменения потребностей проекта может меняться и состав этих подкоманд |
Проект по внедрению любой информационной системы требует активного взаимодействия участников команды, как со стороны заказчика, так и подрядчика. Цель взаимодействия — обеспечить управление ожиданиями сторон в рамках проекта, и как результат — максимальное соответствие результирующей системы исходным потребностям бизнеса. Эффективное взаимодействие также необходимо для того, чтобы функционирование и развитие системы в дальнейшем встречало понимание со стороны пользователей и обслуживающего технического персонала.
Мы предполагаем, что как минимум следующие "роли" должны войти в проектную команду со стороны заказчика:
Лидер группы заказчика работает в постоянном контакте с менеджером проекта со стороны подрядчика, следя за тем, чтобы все поставленные задачи были выполнены в срок и правильно. Если возникают какие-либо вопросы, лидер группы заказчика совместно с менеджером проекта подрядчика обсуждают эти вопросы и находят взаимовыгодное решение. Функциональные обязанности лидера группы заказчика:
Лидер группы заказчика выступает для сотрудников компании подрядчика в качестве главной "точки контакта" — через него происходит доступ к информации, контакт с другими сотрудниками организации заказчика.
Лидер группы заказчика должен обладать необходимыми полномочиями для того, чтобы утверждать технические требования, принимать работу, авторизовать расходы в рамках выделенного на проект бюджета. Если лидер группы заказчика не наделен подобными полномочиями в полном объеме (или осознанно не хочет пользоваться этими полномочиями, чтобы не брать на себя дополнительную ответственность), он превращается в лишнее связующее звено между подрядчиком и сотрудниками своей организации, которые действительно принимают решения. Это, в свою очередь, приводит к затягиванию проекта, неразберихе, многократным переделкам и неэффективному использованию ресурсов.
Для каждого из основных функциональных блоков системы в вашей организации — продаж, маркетинга, поддержки, удаленных агентов и т.д. — должен быть назначен ответственный специалист по использованию системы. Каждый такой специалист должен быть знаком с операционными процедурами, связанными с использованием соответствующих функциональных модулей. После окончания процесса внедрения он будет выступать основным "носителем знаний" по возможностям системы для дальнейшего развития и обучения пользователей.
Обязанности специалиста по использованию системы:
Вы должны определить главное лицо, ответственное за все вопросы или проблемы, возникающие в процессе использования системы. Специалист по поддержке должен обладать всесторонним пониманием процессов работы системы и уметь принимать оперативные технические решения.
Обязанности специалиста по поддержке системы включают:
Системный администратор отвечает за аппаратное и программное обеспечение, необходимое для эффективной работы системы в целом — операционной системы, сервера баз данных и т.д. Системный администратор должен обладать необходимой квалификацией для настройки и поддержки данного аппаратного и программного обеспечения или должен пройти соответствующие курсы обучения для приобретения этих навыков в необходимом объеме.
Обязанности системного администратора:
Производители систем и компании-интеграторы обычно предоставляют специализированные курсы обучения для системного администратора и резервного сотрудника — по вопросам безопасности, администрирования прав доступа, резервного копирования и архивирования данных и других административных функций.
Во многом успех проекта зависит от квалификации и способностей руководителя проекта со стороны подрядчика, который отвечает за общий ход реализации проекта. Он координирует ежедневные задачи всех участников команды и отслеживает статус по каждой задаче или контрольной точке.
Руководитель проекта со стороны подрядчика встречается с лидером группы заказчика для обсуждения статуса продвижения по каждой из задач проекта и разрешает возникающие противоречия или недопонимания. Прямые обязанности менеджера проекта включают:
Если возникают задержки в текущем графике реализации или другие проблемы, руководитель проекта отвечает за их разрешение после консультации с лидером группы заказчика.
Проектная команда подрядчика состоит из нескольких квалифицированных специалистов. Они назначаются руководителем проекта в соответствии с потребностями проекта. Основная задача специалистов — сбор и формализация требований, внедрение системы в требуемом объеме, настройка, проверка работоспособности и т.д.
Следующие роли специалистов подрядчика могут быть задействованы в вашем проекте (один специалист может сочетать в себе несколько ролей одновременно, если его квалификация позволяет это сделать).
Правильное планирование — половина пути к успеху, когда речь идет о внедрении сложной информационной системы. На этапе запуска проекта специалисты вашей компании совместно с внешними консультантами подрядчика определяют потребности бизнеса и составляют план внедрения системы. Они также определяют методы конвертации данных и формулируют риски и факторы оценки успешности проекта.
На основе информации, собранной во время предварительных встреч по проекту, создается план-график проекта. Этот план является основным указателем на пути продвижения от одной стадии реализации проекта к следующей. План модифицируется по мере реализации проекта, чтобы соответствовать всем запросам, которые не могли быть четко идентифицированы на первых этапах. В дополнение к этому специалисты проектной команды отслеживают все вновь возникающие сложности и ограничения — для того, чтобы соответствующим образом через систему управления запросами вносить изменения в план-график проекта и документацию.
Все это делается для того, чтобы обеспечить "управление ожиданиями", т.е. сделать процесс реализации проекта максимально прозрачным для всех его участников. В каждый момент времени, вне зависимости от того, насколько далеко текущий план проекта эволюционировал относительно начальной бизнес-концепции, проект соответствует ожиданиям заказчика по срокам, объемам выполненной работы, функциональным возможностям системы. При этом проект соответствует и ожиданиям компании-поставщика решения по срокам, бюджету, накоплению профессионального опыта.
Расписание событий, представленное в план-графике проекта, строится на основе ключевых контрольных точек, которые определяются требованиями бизнеса и корпоративного распорядка. Например, может потребоваться учесть корпоративные события или праздники, которые попадают на период реализации проекта, определить сроки установки и конфигурирования аппаратного и программного обеспечения в соответствии с графиком их поставки, привязать срок сдачи проекта в целом или каких-либо его этапов к ключевым событиям (началу сезона продаж, слиянию компаний, собранию акционеров и т.д.).
План-график проекта проще всего создать в среде Microsoft Project или другой автоматизированной системе управления проектами, которая принята в вашей компании или у подрядчика. Необходимо, чтобы эта система позволяла создавать отчеты по любым аспектам текущего состояния проекта, отслеживать ключевые контрольные точки, задержки в расписании, сравнивать исходный план с существующим на текущий момент прогрессом.
Контроль за ходом развития проекта происходит на основе формальных статусных отчетов (status report), а также неформальных встреч и обсуждений. Такой подход позволяет разрешать все вопросы и противоречия на ранних этапах их возникновения и гарантирует, что усилия по внедрению соответствуют задачам, определенным в исходных документах.
За счет использования плана-графика проекта достигается следующее:
Проект внедрения системы CRM состоит из следующих основных этапов (некоторые могут осуществляться параллельно):
Очень важное событие в истории проекта внедрения. Напряжение, связанное с процессом выбора системы и поставщика, уже позади. С другой стороны, участники проекта еще не погрузились в рутину внедрения, многие даже не понимают своей роли в проекте. Грамотно проведенная встреча по запуску проекта может сэкономить нервы и ресурсы на последующих этапах, когда оправдания типа "я думал(а), что нужно делать такѕ" и "мне никто не сказал, что я должен(на) подготовить эти документыѕ" начнут сыпаться со всех сторон.
Встреча по запуску проекта планируется с ключевыми менеджерами и техническими сотрудниками. Мы очень рекомендуем, чтобы лидер группы заказчика, бизнес-заказчик из числа топ-менеджмента, специалисты по использованию системы участвовали в этой встрече, так же как и другие сотрудники, которые должны внести вклад в процесс внедрения системы. Во время встречи участники стараются максимально глубоко понять объемы работ, общее направление развития и ожидания руководства.
Во время встречи по запуску проекта решаются следующие вопросы:
Имея более четкое представление о поставленных целях, профессиональная команда подрядчика может лучше определить ключевые контрольные точки и события. Приоритеты к моменту запуска проекта могут сильно измениться относительно тех, что были сформулированы в процессе предварительных обсуждений. На встрече по запуску проекта определяются средства взаимодействия между участниками команды, а также формат отношений с другими сотрудниками компании заказчика.
После встречи по запуску проекта проектная команда должна обладать необходимой информацией для раскладки процесса внедрения, выделения ресурсов, составления расписания и распределения задач между исполнителями — определить потребности, конвертацию данных, установку и конфигурирование системы, тестирование и интеграцию. График встреч проектной команды, интервью с ключевыми менеджерами и проектным персоналом, доступность аппаратного и программного обеспечения — все эти параметры нельзя упускать из виду, чтобы гарантировать, что процесс настройки, тестирования, установки, обучения и интеграции уложится в запланированные рамки.
План включает ключевые контрольные точки, действия ответственных сотрудников с обеих сторон. Исходный план-график, который, возможно, составлялся на этапе выбора решения, должен быть расширен и уточнен в соответствии с текущими потребностями бизнеса. После утверждения заказчиком план-график служит основой для дальнейшего развития проекта.
В рамках этой стадии реализации проекта необходимо определить потребности каждой из групп потенциальных пользователей системы. Определение функциональных потребностей предполагает серию интервью, проводимых членами проектной команды с руководителями и сотрудниками различных департаментов компании. Посредством этих интервью мы определяем и описываем следующие составляющие бизнеса:
На этом этапе специалисты не пытаются построить детальный дизайн системы, а просто определяют ключевые функциональные требования и расставляют приоритеты по важности и сложности реализации для каждого из требований. Они также пытаются определить наиболее эффективные пути достижения поставленных целей по управлению клиентскими взаимоотношениями. Задача заключается не просто в том, чтобы перенести существующие процессы на новую платформу, но и в том, чтобы найти пути улучшения их работы за счет использования новых технологий и функций системы.
По окончании серии интервью готовится документ по функциональным требованиям. Он определяет все ключевые функциональные требования. Он также определяет наиболее критичные модификации, которые необходимо внести в систему прежде, чем можно будет проводить обучение пользователей и установку приложений на рабочих местах.
Данный документ необходим не только для того, чтобы формально зафиксировать функции, которые система должна осуществлять. Он также дает возможность руководству компании заказчика принимать взвешенные решения об использовании существующего бюджета на те из задач, которые являются наиболее приоритетными и при этом имеют минимальную стоимость реализации.
В процессе реализации проекта команда внедрения осуществляет доработки системы в соответствии с требованиями бизнеса. Все изменения и доработки разбиваются по фазам в зависимости от приоритета задачи и сложности ее реализации. Для каждой фазы определяется, какие функции должны быть реализованы. Насколько это возможно, каждое требование разбивается на минимальные блоки, которые можно использовать и тестировать по отдельности. Таким образом, достигается максимальная скорость ввода реализованной функциональности в эксплуатацию для конечных пользователей, чтобы предоставить им возможность протестировать данную функцию и начать ее использование.
Каждая доработка документируется и утверждается прежде, чем начинается ее реализация. Каждое изменение исходной системы сопровождается оценкой по объемам ресурсов, а также временным диапазоном, необходимым для реализации и тестирования данной функции. Форма документирования доработки включает следующие параметры:
После утверждения данного изменения заказчиком оно включается в план-график проекта, и на него выделяются соответствующие ресурсы. После этого заказчик получает обновленный план-график проекта с учетом новой задачи.
Мы уверены, что лучший способ создания хорошей системы — постоянный контакт с конечными пользователями этой системы в процессе внесения в нее доработок и изменений. Когда задача по доработке утверждена и запущена в работу, специалист вносит соответствующие исправления в систему и сразу же представляет их пользователям для получения от них обратной связи. Часто требуемые изменения могут быть внесены за считанные минуты и сразу же на месте представлены для рассмотрения, если встроенный инструментарий архитектурного проектирования (такой, как SalesLogix Architect или Siebel Tools) позволяет это сделать. Таким образом, пользователям предоставляется возможность участвовать в процессе построения системы еще до обучения ее использованию.
Для каждой фазы внедрения, на которой осуществляются доработки системы, проводится тестирование на основе пробных данных в формате и структуре, соответствующих реальным данным. Затем система тестируется при помощи использования копии реальной базы данных. После достижения требуемых параметров целостности и производительности системы в нее вносятся соответствующие доработки, которые затем тестируются на пробных данных, а потом — на копии реальных данных. Только после того как достигается общая целостность системы, она устанавливается для тестирования в существующую бизнес-среду предприятия (параллельно с существующими бизнес-процессами).
Одним из видов сервиса, предоставляемого компаниями-интеграторами, является конвертация существующих данных в новую систему. Многолетняя история работы с клиентами может представлять собой довольно большой массив данных, который вы захотите частично или полностью конвертировать в систему CRM. Чем больше информации должно мигрировать из старых форматов в новую систему, тем дольше может длиться процесс внедрения. В рамках проекта компания-интегратор обычно осуществляет конвертацию всей информации о существующих и потенциальных клиентах, которая имеется в структурированном электронном виде. Эта информация обычно включает как минимум имена клиентов, их адреса, типы, номера телефонов и факсов, ключевые контакты. Если информация недоступна в электронном виде, можно ввести вручную данные о 20% лучших клиентов, которые создают наибольший объем бизнеса для вашей компании. Для этой цели можно использовать временного сотрудника. Информация о других клиентах может быть введена позже, по мере необходимости.
Если информация о клиентах существует в электронном формате, она обычно может быть конвертирована в формат любой CRM-системы. Наиболее удобным форматом файлов для конвертации является "текст, разделенный запятой" (*.csv). Большинство программ для управления контактной информацией — такие, как Microsoft Access, Excel предоставляют данную опцию для экспорта.
Также возможно подключить данные напрямую через таблицы удаленной базы данных, такой как Access, Oracle или Microsoft SQL. В дальнейшем эти связи между таблицами можно использовать для импорта данных.
В процессе конвертации данных вы можете захотеть "подчистить" свои данные о клиентах. Например, старые клиентские записи компаний, с которыми вы больше не работаете. У вас также могут попадаться
Учитывая, что ваша клиентская база данных может сильно отличаться от стандартной, вам может быть интересно запустить различные фильтры, которые могут изменять значения определенных полей для консолидации данных или автоматически вводить пустые поля, такие, например, как "город" в адресе.
В любом случае компании-интегратору потребуется ваша помощь для того, чтобы определить конкретные требования к конвертации данных. Чтобы избежать неприятных сюрпризов на финальных стадиях проекта, необходимо как можно более детально определить требования к конвертации и объемы работ на ранних стадиях проекта.
Если вы хотите, чтобы проект уложился в запланированные сроки, необходимо, чтобы все требуемое оборудование было подготовлено и сконфигурировано до начала разработки и обучения сотрудников. Также необходимо подготовить все рабочее пространство, чтобы потом не терять на это время. В частности, это включает не только подготовку компьютеров на рабочих местах и в серверной, но и проверку кабельной сети, наличие необходимых компонентов. Если предполагается проводить обучение в вашем офисе, необходимо позаботиться о подготовке и оборудовании помещения для проведения обучения.
В широком смысле подготовка рабочего пространства включает следующие основные шаги.
Анализ и оценка существующей конфигурации компьютеров (пригодность для работы системы):
Во время этого этапа происходит установка системы на оборудование заказчика, а также тестирование на предмет целостности и совместимости с существующей инфраструктурой. Перед инсталляцией системы необходимо проверить следующие параметры:
Стандартный набор установки системы SalesLogix может включать, например, следующие компоненты:
Ответственным этапом в процессе внедрения автоматизированной системы является обмен данными с унаследованными информационными системами.
Под термином "унаследованная система" мы подразумеваем информационные системы, которые используются в организации уже значительное время и имеют ограничения по формату взаимодействия или доступа к данным.
До начала проекта мы рекомендуем выписать и кратко характеризовать возможности всех существующих в вашей компании систем автоматизации, с которыми предполагается интеграция. Также необходимо сформулировать потребности в периодическом обмене данными с этими системами (включая периодичность обмена, размер, структуру и описание формата данных). Будет полезно включить контактные имена и номера телефонов сотрудников, которые лучше всего знакомы с каждой из существующих унаследованных систем.
Обучение является неотъемлемой частью любого процесса внедрения. Компании-интеграторы обычно предлагают несколько различных курсов в зависимости от специфики проекта и потребностей вашей команды.
По мере развития вашего проекта внедрения менеджер проекта со стороны интегратора может предоставить конкретные рекомендации о программе обучения на различных стадиях проекта.
Обучение администраторов покрывает вопросы архивации баз данных, управления пользователями, безопасности, добавления новых лицензий, использования механизмов синхронизации данных, поддержки библиотеки документов, управления скриптами.
Техническое обучение по использованию средств архитектурного проектирования является необязательным. Большинство компаний предпочитает обращаться к профессиональным консультантам для внесения изменений в функциональность системы в процессе ее эксплуатации. Если вы хотите лучше понять, как создавать новые отчеты, шаблоны или делать основные изменения в базе данных и формах ввода данных, интегратор предоставит услуги по техническому обучению администраторов баз данных и других сотрудников ИТ, которые будут осуществлять модификации в системе.
Мы считаем, что наиболее эффективным способом обучения технического персонала является тесный контакт с профессиональными консультантами на этапе внедрения системы. Цель технического персонала заказчика в процессе внедрения — накопление опыта для дальнейшей самостоятельной поддержки и развития системы.
Полноценное обучение пользователей — один из наиболее важных факторов успеха проекта. Изменение процессов продаж и маркетинга может оказать огромное влияние на повседневную жизнь компании. Некоторые пользователи могут не принять изменения. Только если конечные пользователи чувствуют себя уверенно в работе с системой, переход на нее произойдет безболезненно.
Любое обучение пользователей включает сочетание домашнего чтения и занятий в классе. Обучение в классе может происходить как на территории центра обучения, так и в офисе заказчика.
Для обучения в офисе заказчика необходимо оборудовать помещение для данных целей, которое должно включать следующее оборудование:
Каждому слушателю понадобится собственный компьютер, соответствующий минимальным требованиям для работы приложений. Мы рекомендуем, чтобы компьютеры слушателей были теми же, что они планируют использовать в дальнейшем для работы в системе. По возможности небольшая локальная сеть может быть использована для обучения.
Иногда имеет смысл перенести обучение пользователей в класс за пределы офиса, чтобы ежедневная работа в офисе не отвлекала сотрудников и не снижала эффективность обучения.
Для того чтобы ваша компания могла эффективно использовать технологии CRM в работе, необходимо наличие двух типов специалистов для дальнейшей поддержки системы — системного аналитика и администратора системы ИТ. От эффективности работы этих сотрудников во многом будет зависеть, сможет ли компания достигнуть поставленных целей в области автоматизации клиентских взаимоотношений.
Системный аналитик отвечает за все вопросы применения системы, т.е. правила доступа к данным, безопасность и разграничение полномочий, процесс ведения клиента. В широком смысле — за любые точки взаимодействия пользователей с данными в системе. Он должен обладать глубокими знаниями сути бизнеса, который ведет ваша компания, включая (но не ограничиваясь этим) продажи, маркетинг и поддержку пользователей. Также эта роль требует знакомства с сотрудниками организации (или департаментами) и их основными функциями. Главной задачей данного специалиста является эффективное применение "бизнес-правил" вашей компании в системе.
Понимание CRM-системы. Требуется хотя бы поверхностное понимание функциональности системы и ее технологических возможностей для того, чтобы принимать взвешенные решения по техническому использованию инструментов системы. Необходимо знание таких понятий, как структура таблиц, безопасность/доступ групп и пользователей, пункты меню, доработка функциональности, процессы синхронизации информации.
Правила доступа к данным и управление процессами. Этот вопрос обычно является наиболее важным, однако он часто упускается из виду. Когда много пользователей начинают работу в системе с одними и теми же данными, необходимо четко регламентировать процесс работы с этими данными. Обычно для этого собирается рабочая группа, которая состоит из представителей конечных пользователей, системного администратора и системного аналитика. Правила, разрабатываемые этой группой, должны включать все аспекты — начиная форматом ввода данных в поля форм и кончая определением процессов продаж и единого формата наименований потенциальных сделок; от решения о том, как формируется маркетинговый источник, до координации обмена данными с унаследованными системами. Однако эти правила должны быть введены в действие, постоянно отслеживаться и совершенствоваться по запросам бизнеса. Системный аналитик должен быть очень хорошо знаком с практикой ведения бизнеса в вашей компании для того, чтобы разрабатываемые им модели использования си стемы подходили к требованиям бизнеса.
Планирование задач. Системный аналитик также будет отвечать за планирование и расписание задач по проекту таким образом, чтобы не возникало конфликтов по срокам, например, чтобы плановая
Актуализация пользовательской документации и программы обучения пользователей. Другим важным аспектом использования системы является постоянная актуализация пользовательской документации и программы обучения пользователей, документирование всех важных функций и правил работы с данными, связанных с использованием "вашей" системы. За счет поддержки актуальной документации и программы обучения все новые пользователи системы смогут добиться продуктивности значительно быстрее.
Администратор системы ИТ отвечает за все технические аспекты работы и поддержки системы и ее конечных пользователей. Этот сотрудник обычно внедряет решения, принятые системным аналитиком, но также и помогает ему лучше понять технические ограничения этих решений.
Понимание технологий системы. Глубокое понимание системы на уровне технологий работы — обязательное требование для внесения изменений, управления пользователями и данными. Этот сотрудник должен посетить необходимые курсы обучения для администратора системы.
Реляционные базы данных и SQL-запросы. Базовые необходимые знания о том, как работает SQL-сервер или Oracle, в зависимости от используемой платформы, а также как строятся SQL-запросы. Также требуется понимание следующих понятий:
Операционная система на рабочих местах (Windows 95/98 или 2000) — минимальное необходимое понимание принципов работы операционной системы, ее архитектуры и принципов взаимодействия между операционной системой и системой CRM.
Отчеты — навыки построения отчетов в соответствии с вашими корпоративными стандартами и умение применить эти навыки для решения аналитических потребностей компании.
Web — понимание основных Web-технологий (HTML /
Ежедневные обязанности администратора системы ИТ могут включать.
| Управление пользователями, группами и уровнями доступа к информации. Создание и актуализация БД для удаленных пользователей. Управление дополнительными модулями. Создание отчетов. Управление импортом/экспортом данных. Контроль активности удаленных пользователей. Мониторинг пользовательской активности |
Установка и модификация ПО. Решение проблем с операционной системой. Администрирование Решение проблем с синхронизацией Резервное копирование и поддержка БД. Установка и настройка баз данных. Мониторинг системы и дискового пространства |
По статистике, около 70% всех проектов в сфере корпоративной автоматизации заканчиваются неудачами (заказчик не достигает поставленных целей). Почему так происходит? Перефразируя классика, можно сказать: "Все успешные проекты успешны одинаково, все неудачные — неудачны по-своему".
Как мы уже неоднократно отмечали, автоматизация процессов взаимоотношений с клиентами — это не столько внедрение конкретного программного решения, сколько бизнес-стратегия, обучение и мотивация конечных пользователей. Подобная работа часто связана с ломкой существующих устоев, борьбой со стереотипами и предрассудками.
Критические факторы успеха использования систем CRM закладываются еще на стадиях разработки бизнес-требований к системе и ее внедрению. Если руководство компании принимает решение о переходе на подобный инструмент управления отношениями с клиентами, оно должно обеспечить не только технологическую базу, но и выработать четкие бизнес-цели и организационные процедуры/регламенты использования системы. Ошибочно полагать, что система является самодостаточной и по мановению волшебной палочки решит все проблемы в области продаж, маркетинга и обслуживания клиентов.
Тем не менее можно выделить несколько основных причин неудач проектов — в сфере CRM в первую очередь (хотя многие из данных причин характерны и для других проектов автоматизации).
Среди наиболее частых причин неудач можно выделить следующие (расположены в порядке убывания приоритета):
Ниже мы рассмотрим более подробно каждую из указанных причин.
Разница между "стратегией" и "системой" CRM заключена в пользователе, который сидит за интерфейсом системы. От него зависит, смогут ли трансформироваться данные и процессы, заложенные в систему, в конкретные преимущества для бизнеса. Несмотря на то что преимущества внедрения системы для компании в целом могут быть очевидны для руководства, это совершенно не означает, что каждый конкретный пользователь на своем рабочем месте также осознает важность и необходимость использования системы.
Учитывая, что система помимо всего прочего является мощным контрольным механизмом, позволяющим количественно оценить эффективность работы каждого конкретного сотрудника во взаимодействии с клиентами, многие сотрудники воспринимают подобную инновацию "в штыки". Иногда приходится даже говорить о целевом саботаже использования системы со стороны сотрудников отдела продаж и маркетинга, не желающих испытывать дополнительное давление и надзор со стороны "бездушного компьютера".
Единого рецепта борьбы с этой проблемой не существует, так как в каждом конкретном случае он зависит от целого ряда факторов, например:
Тем не менее практически всегда преодоление нежелания сотрудников строится по принципу "кнута и пряника", где в качестве "кнута" могут выступать такие требования.
В качестве "пряника" в свою очередь могут выступать:
В целом необходимо отметить, что сотрудники, непосредственно работающие с системой, являются скорее сторонниками, нежели противниками руководства компаний в стратегии CRM. Их система мотивации должна строиться больше методом "пряника". Функции контроля должны быть разумными и справедливыми, в этом случае проблем с использованием системы можно избежать.
Есть варианты объединения возможностей и "кнута", и "пряника" в рамках единого метода, например:
"Постоянное и активное использование системы в рамках регламента, установленного в отделе, автоматически предполагает получение сотрудником дополнительной премии в размере $50 в месяц.
Нарушение регламента или отказ от использования системы в предусмотренном регламентом объеме автоматически предполагает штраф в размере $100 в месяц".
Отдельно необходимо упомянуть о нежелании сотрудников пользоваться системой, вызванном примитивным незнанием ее функций и страхом перед новым технологическим инструментом.
Ряд простых, но действенных мер поможет раз и навсегда решить эту проблему:
Как мы уже отмечали выше, несоответствие ожиданиям является одной из наиболее серьезных проблем любого проекта автоматизации, тем более в сфере CRM.
Красивая и яркая презентация возможностей CRM, получение всех запрашиваемых на проект ресурсов и полномочий в результате может привести скорее к негативному результату, если успехи проекта, пусть даже вполне весомые, не будут соответствовать тому пониманию, которое сложилось изначально в умах руководителей предприятия. "Это все, конечно, хорошо. Но вы же говорили, что после внедрения системы продажи могут вырасти на 300%, а они выросли только на 50%. Правильно ли будет и дальше финансировать этот проект?" — такой ответ ошарашит руководителя проекта, но будет вполне закономерным, если не побеспокоиться об управлении ожиданиями с самого начала реализации проекта.
Бюрократия и формализм — главные союзники менеджера проекта в преодолении данной проблемы. Правильным ответом на провокационный вопрос руководителя в этом случае будет: "Если вы заметили, в финансовой модели, которую мы совместно утвердили, рост продаж в 300% предполагается только в случае наличия дополнительного финансирования, которое вы на прошлой встрече посчитали рисковым. Возможно теперь, когда вы видите успехи нашего проекта, вы подтвердите данный бюджет".
Существует большое количество различных подходов, которые можно использовать для управления ожиданиями заинтересованных сторон и, соответственно, их однозначной трактовки в случае несоответствия ожиданиям. Один из подходов, принятый в компании McKinsey, приведен на схеме ниже. Суть его заключается в осуществлении трех последовательных шагов:
Кто-то может посчитать этот подход слишком "показушным": концентрируясь на "быстрых победах", можно потерять из виду долгосрочные стратегические приоритеты. Однако обширная практика множества компаний показывает, что данный подход всегда приносит максимальную отдачу с точки зрения управления ожиданиями, а время, потраченное участниками проектной команды на формирование и систематизацию целей, рычагов, показателей эффективности, с лихвой компенсируется устойчивым развитием проекта в целом.
Не один проект CRM закончил свой век на архивной полке "Полные провалы" по одной простой причине: руководители предприятия, в целом заинтересованные в успехе проекта, тем не менее не уделяли ему достойного уровня внимания, а ответственные специалисты не обладали необходимым авторитетом или полномочиями для решения ключевых стратегических задач.
К сожалению, часто невозможность решения этой проблемы связана с менталитетом высших руководителей компании. На встречах с собственниками и высшими руководителями крупных и вполне успешных компаний на вопрос: "Как нам стать более клиенто-ориентированными?" хочется ответить: "Начните с увольнения себя и найма более квалифицированного руководителяѕ". Хороший собственник, предприниматель, талантливый производственный руководитель тем не менее, не всегда может управлять процессами взаимодействия с клиентами, часто не хочет принимать новые правила игры в конкуренцию. В этом случае требовать подобных кардинальных изменений от его подчиненных также не приходится.
Но даже когда руководитель сам понимает ценность и важность внедрения стратегии CRM, он зачастую разрывается между несколькими задачами с не менее высоким приоритетом и не может уделять достаточно внимания операционным вопросам.
Учитывая большой объем организационных и структурных изменений, с которыми связан любой проект CRM, в нем не обойтись без такой роли, как
Для увеличения эффективности взаимодействия со
Определяется круг стратегических вопросов, по которым требуется вмешательство спонсора проекта. Этот круг должен быть достаточно небольшим, однако спонсор должен предоставить гарантии того, что по каждому из этих вопросов он сможет найти время для их решения. Если решение не требует эскалации, менеджер проекта должен иметь возможность решить его без привлечения высшего руководства. Например, использование проектного бюджета в оговоренных рамках не должно требовать дополнительной санкции директора, однако любые изменения в смете должны быть немедленно представлены спонсору с подробным объяснением.
Мечта любого руководителя — постоянно иметь на своем рабочем столе "пульт управления" бизнесом с несколькими индикаторами. Если все идет хорошо по тому или иному направлению, индикатор горит зеленым цветом и можно не беспокоиться. Если загорается желтый или красный свет, необходимо вмешаться.
Если отчетность по проекту организована таким образом, что
С другой стороны, в вопросах надзора со стороны высшего руководства действует принцип "У семи нянек дитя без глазу". Слишком много внимания и надзора может быть также губительно для проекта, как и полное их отсутствие.
"Пока гром не грянет, мужик не перекрестится". Запуск CRM-проекта — серьезный шаг для руководства компании. И для того чтобы на него решиться, часто необходимо, чтобы объем накопившихся проблем и задач достиг определенного критического порога.
Соответственно, решившись на реализацию проекта, руководство компании часто пытается "заодно" решить целый ворох смежных или связанных задач, которые существенно увеличивают сложность, продолжительность и риски проекта.
На схеме ниже приведена статистика зависимости отдачи проекта от его сложности (продолжительности). Как видно, существует устойчивая обратная зависимость, т.е. чем сложнее (длиннее) проект, тем выше вероятность того, что он не достигнет поставленных результатов, будет отложен или вовсе остановлен (что обычно говорит о полном провале проекта).
Для того чтобы избежать этой проблемы, необходимо четко делить проект на непродолжительные последовательные стадии (от двух недель до трех месяцев каждая). По каждой стадии необходимо четко определять цели, рычаги и показатели эффективности, причем начинать надо с реализации наиболее понятных, простых и очевидных задач. Более сложные, неопределенные, конфликтные задачи — откладывать на последующие стадии с целью их лучшей проработки и формализации по мере реализации более простых.
От менеджера CRM-проекта часто требуется не столько знание технологий и методологий, сколько политики и психологии. В сложной иерархии крупной компании от правильной расстановки сил зависит успех любого проекта, тем более в сфере
Как минимум любой проект CRM затрагивает три разных подразделения:
Перекос в сторону интересов одного из данных подразделений может стать существенным фактором риска всего проекта. А представьте, если в проекте участвует более трех управлений? Например, если в компании существует несколько отделов продаж — для каждого типа продукции или услуг, причем у каждого свой набор приоритетов и потребностей...
Стоимость владения является одним из тех факторов, который постоянно упускается из виду при реализации различных стратегических и ИТ-проектов. Опыт реализованных проектов показывает, что исходная цена решения составляет только 20–30% от общей стоимости владения. После запуска системы часто и начинаются основные расходы, на которые средства уже не заложены: поддержка и модернизация, обучение персонала, интеграция.
При оценке экономической эффективности проекта необходимо учитывать все возможные "скрытые расходы", связанные с дальнейшим обслуживанием и развитием проекта.
Можно использовать простую таблицу бюджетирования расходов по основным категориям на 3–5 лет (пример приведен ниже) или принятую в вашей компании процедуру.
| Бюджет | |||
| 1 год | 2 год | 3 год | |
| Оборудование и ПО | |||
| Лицензионное ПО системы CRM | |||
| СУБД | |||
| Оборудование и системное ПО | |||
| Услуги | |||
| Консалтинг и написание ТЗ | |||
| Услуги по внедрению | |||
| Услуги по технической поддержке | |||
| Системная интеграция | |||
| Резерв | |||
| Обучение | |||
| Обучение конечных пользователей | |||
| Обучение технического администратора | |||
| Внутренние ресурсы | |||
| Менеджер проекта | |||
| Бизнес-аналитик | |||
| Системный администратор | |||
| Накладные расходы | |||
| Транспортные расходы (командировки) | |||
| Представительские расходы | |||
| Общий итог | |||
Как мы уже неоднократно отмечали, стратегия CRM не имеет смысла без использования возможностей информационных технологий. Однако это вовсе не означает, что заниматься проектом должны специалисты отдела ИТ.
В нашей практике можно вспомнить лишь несколько проектов, где лидерами проекта внедрения CRM-системы выступали ИТ-специалисты, причем все они сталкивались с одними и теми же проблемами, уже описанными выше. Отсутствие внутреннего спроса со стороны руководителей бизнес-подразделений или чрезмерное увлечение технологическими "наворотами" современных систем заводили подобные проекты в тупик.
Тем не менее руководители компаний продолжают с завидным постоянством направлять любые проекты, связанные с автоматизацией, в ведение ИТ-отдела, тем самым существенно увеличивая риск провала.
Всех этих ошибок можно избежать и снизить риск неудачи при внедрении и использовании системы. Аккуратными, поступательными движениями, избегая методов "взрыва бомбы" или решений "под ключ", можно приучить пользователей к новой культуре эффективной работы с клиентами и использованию соответствующих технологических средств.
70% всех проектов в области автоматизации заканчиваются неудачами! Это слишком высокий показатель для того, чтобы пускать данные проблемы на самотек. Тем более что изобретать велосипед здесь не нужно — многолетний опыт тысяч компаний уже собран в методиках, рекомендациях и технологических решениях. Нужно только уметь их правильно использовать.
Общие рекомендации для тех, кто хочет попасть в счастливые 30% удачных проектов:
Ставить реальные исполнимые цели, не соглашаться на невыполнимые сроки, требовать необходимых полномочий и ресурсов, опираться на четко сформулированные показатели эффективности.
Поставщики решений будут постоянно придумывать новые "большие идеи" и стратегические концепции, призванные увеличить добавленную стоимость предлагаемых программных и технологических решений. Они будут использовать красивые термины для того, чтобы красивее представить обыденные рабочие инструменты. Опирайтесь на функциональные требования и бизнес-приоритеты, а не на концепции при выборе и внедрении решений.
В конечном итоге любой проект автоматизации — это венчурный инвестиционный проект. Используйте раздел "Язык денег" в конце данной главы для того, чтобы лучше понимать терминологию финансовых менеджеров, и оперируйте ею при обосновании проекта и его реализации.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.