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

Проектная концепция от InformUnity

Все статьи

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

Карл Вигерс, посвятивший свою жизнь систематизации подхода к проработке требований к ПО, говорит, что правильный подход к проектированию экономит 30-50 % бюджета разработки. А в нашем опыте заказной разработки встречаются и вовсе парадоксальные факты: отдельные проекты с бюджетом в несколько миллионов закрывались на этапе ввода в эксплуатацию — всё из-за расхождения первоначальных требований с реальностью.

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

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

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

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


Проектная концепция от informUnity

1. Статус документа

Документ подготовлен компанией informUnity (informunity.ru) по заказу компании Horns and Hooves LTD (hornsandhooves.ltd) для выявления и систематизации потребностей Заказчика по автоматизации отдела продаж.

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

Warning! Документ не является окончательной документацией и содержит информацию, требующую тщательного прояснения на этапе проектирования.

2. Общая информация о компании Horns and Hooves LTD

Компания Horns and Hooves LTD разрабатывает и продает программное обеспечение для промышленного производства мыльных пузырей.

Компания имеет представительства в 48 странах. Штат работников: 4 000 человек, 3 уборщицы и басист, из которых 1 500 человек и 2 уборщицы задействованы в отделе продаж и являются потенциальными пользователями будущей системы.

3. Целевая аудитория и особенности бизнеса

3.1. Целевая аудитория

Состоит из 4 условных групп, сформированных на основании особенностей взаимодействия с клиентами Заказчика:

Артикул Описание
Менеджеры по первичным продажам Осуществляют продажи по холодной и теплой базе путем обзвона, написания персонализированных e-mail’ов, общения в чатах и социальных сетях, включая Tinder (используют дыбу). Проводят личные встречи
Менеджеры по повторным продажам Осуществляют продажи по теплой базе контактов, проводят личные встречи и презентации с использованием мобильной дыбы
Аккаунт-менеджеры Осуществляют сопровождение клиентов, предоставляя тем возможность заплатить деньги (много раз). Профессионалы (обходятся без дыбы)
Менеджеры по претензиям Осуществляют моральную поддержку клиентов, используют корпоративные жилетки. Ведут корпоративные аккаунты

В каждой из групп существуют Старшие менеджеры, которые осуществляют контроль за менеджерами своей группы, несут ответственность за АХЧ (включая дыбы).

Менеджеры всех групп, включая старших менеджеров, регулярно отправляются на стажировку на Сахалин, а также в другие группы.

3.2. Особенности бизнеса

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

Менеджеры отделов продаж частично работают удаленно в Кирове, частично — в центральном офисе на Сахалине.

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

4. Описание действующей системы

Компания пользуется самописной CRM на COBOL. Вследствие особенностей языка COBOL систему трудно развивать и поддерживать, зато она нативно интегрирована с мейнфреймами IBM, используемыми в основном продукте компании. Интеграцию следует сохранить. Необходима миграция базы клиентов из старой CRM в новую.

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

ИТ-директор сообщил нам об email-сервере, настроенном в 1996 году канадским специалистом по телекоммуникациям. Заказчик просит перенести все настройки рассылок в новую систему.

5. Описание проблем

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

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

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

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

ИТ-инфраструктура компании устарела и просится на свалку.

Техническая поддержка перегружена запросами, на которые она не знает ответов.

6. Рекомендации

Для выполнения целей проекта с учетом указанных выше проблем рекомендуется:

  • Внедрить современную CRM Битрикс24

  • Внедрить современные способы коммуникации с клиентами, включая Открытые линии Битрикс24 и VoIP-телефонию на основе Asterisk и FreePBX

  • Шаблонизировать коммерческие предложения по типам с возможностью персонализации и добавления новых шаблонов

  • Создать базу знаний техподдержки, а также дополнительные, более дешевые каналы поддержки пользователей — форумы, FAQ, брендированные бубны и т.п.

  • Интегрировать проверку контрагентов и паспортных данных для предотвращения злоупотреблений со стороны менеджеров

  • Автоматизировать взаимодействие отдела продаж с отделом разработки на основе Бизнес-процессов в Битрикс24

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

  • Доработать стандартный интерфейс Битрикс24 для удобной работы лиц с ограниченными возможностями

  • Внедрить систему автоматического контроля оплат и уволить всех аккаунт-менеджеров

  • Автоматически генерировать строгую отчетность по результатам оплат и отправлять ее контрагентам

7. Список интеграций

  • Почтовый сервер 1996 года (миграция настроек)

  • Самописная COBOL CRM (миграция данных)

  • Интеграция с мейнфреймами IBM

  • Настройка интеграции Asterisk и FreePBX

  • Интеграция релейной АТС (под вопросом)

  • Интеграция системы проверки контрагентов и паспортных данных (требуется выбрать)

8. Риски и зависимости

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

Перевести часть увольняемых менеджеров в уборщицы.

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


Этот документ — первый блок в фундаменте проектной документации. За его составлением следуют основные этапы проектирования:

  • Исследование и описание бизнес-процессов, а при необходимости — и их формализация;

  • Функциональное проектирование и создание прототипов интерфейсов;

  • Техническое проектирование (описание структуры данных, способа обмена с внешними системами, миграций).

Заказать услугу по разработке проектной концепции можно в нашем магазине.

В следующих статьях мы поделимся деталями процесса проектирования. Оставайтесь с нами!


Шерер

Автор статьи: Павел Шерер