Форум Сообщества Аналитиков

×


Описание требований к CRM(Прочитано 84877 раз)
Re: Описание требований к CRM Ответ #30 : 05 Апреля 2008, 11:58:15
Замечания по документации проекта и содержанию

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

2. Анализ проблем отсутствует и проблемы сразу объявлены. Кроме того проблем слишком много, а корневые причины не определены

3. Цели заявленные во многом качественные, а критерии достижения? измеримость?
например: 2.1.9   Увеличить контролируемость Закупок и улучшить планирование Закупок - это что будет значить, как это определить, что контролируемость увеличена и планирование улучшено?
 далее выпишу за счет:
за счет консолидации информации и удобного пользовательского интерфейса
за счет консолидирования информации и повышения доступности документов
за счет консолидирования всех Заявок и возможности постоянного контроля со стороны руководства
за счет консолидирования информации
за счет быстрого получения необходимых требований (Заявки) Клиента
за счет консолидирования информации и хранения полной (всей) информации по работе с Заявками Клиента

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


Далее напомню, что CRM классифицируется на оперативный, аналитический и коллаборационный. Вопрос: какого типа cRM планируется внедрять? оперативный насколько я понял. с элементами аналитического, коллаборационный как я понимаю не катит...

Ошибки по тексту:
3.1.2   Менеджер проекта (МП)
Выполняет работы по обработке Заявки от Клиентов, контролирует процесс выполнения Заявок на более низком, чем Руководитель, уровне.

3.2.6   Сметчик (С)
Будет создавать ТУ, ТЗ, ТП, ИД и КП по Заявке от МП.

3.2.9   Курьер (К)
Курьер будет поставлять оборудование в Компанию и доставляет его Клиентам.
не согласованность времен

3.2.10   Секретарь(С)
Будет заводить новую Заявку и необходимую информацию о Клиенте
Заводить Клиента, это наверное важное действо, но к делу не относящееся

3.3.1   1С
Требует большой настройки Системы и, следовательно, дорогое решение. Нет веб интерфейса.
какая версия имеется в виду, не рассмотрена система 1С Битрикс, не приведены цены, не приведены цифры внедрений CRM от 1С.

Функциональные характеристики описаны как-то по-школьному что ли.
Заведение? Может уж сразу управление (ввод, хранение, изменение, удаление, просмотр, поиск)

Смотрим domain model - на мой взгляд модель слишком бедная. Что касается заявки. Заявок много все-таки, заявки исполняются менеджерами, есть какой-то список заявок на исполнение, распределенный по менеджерам, по сути есть некий график - на модели никак это не обозначено. Мне кажется слишком рано проведено обобщение.

Модель вариантов использования слабенькая, ни ранжирования ВИ, ни распределения ВИ по пользователям, вообще название ВИ не нравятся, что это значит  Завести Заявки....

Войти в систему:
2.3.1.3.1   Пользователь запускает программу (Систему)
2.3.1.3.2   Система показывает форму авторизации, см. ПИ
2.3.1.3.3   Пользователь вводит свои имя и пароль и нажимает кнопку ОК
2.3.1.3.4   Система подтверждает введенные имя пользователя и пароль и показывает пункты меню, доступные для данного пользователя, см. БП

Все - никаких если, никаких проверок - типичная ошибка начинающего техписа по ВИ, смотри КОБЕРНА

2.3.1.4   Альтернативные сценарии
2.3.1.4.1   Пользователь ввел неверные имя и пароль, п. 2.3.1.3.4
2.3.1.4.1.1   Если пользователь ввел неверные имя и пароль, то Система показывает соответствующее сообщение
2.3.1.4.1.2   Пользователь нажимает ОК на Сообщении
2.3.1.4.1.3   Выполнение продолжается с п. 2.3.1.3.2 основного сценария
Слишком рано и похоже на реализацию
                       Данные введенные пользователем не верны!
                       Система выдает соответствующее сообщение и перенаправляет                  пользователя на страницу входа

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

2.3.1.4.2   Пользователь нажимает кнопку ОТМЕНА, п. 2.3.1.3.3
2.3.1.4.2.1   Если Пользователь нажал кнопку ОТМЕНА, то Система закрывает приложение
Это же веб приложение, имеет ли смысл вот так раз и закрывать приложени, по сути не приложение будет закрыто а браузер

2.3.1.5   Выходные условия
Пользователь успешно вошел в Систему
вовсе нет, пользователю предоставлен доступ к информации в соответствии с правами доступа!

2.3.2.3.2   Система показывает форму Справочника, которая показывает отображает лучше все элементы Справочника с полями в соответствии с выбранной ф-тью:
нужно все-таки стараться писать литературно, но точно

Сценарий описан по сути как дерево решений: если - то, может так и писать? а не через ВИ? Мне не нравится, смотри выше. Коберну икается

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


Про бизнес-процессы. Мне кажется их следует описывать в стиле событие - действие событие - то есть eEPC или BPMN.

Нет общей картины, бизнес-плана...
« Последнее редактирование: 05 Апреля 2008, 12:26:12 от Galogen »



Re: Описание требований к CRM Ответ #31 : 07 Апреля 2008, 19:53:01
Цитировать
По-моему совсем было бы не лишним предоставить документ требования
(запросы) заказчика или оценка целевой организации. Это дает более четкое
ощущение контекста и понимание проблематики

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

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



Re: Описание требований к CRM Ответ #32 : 08 Апреля 2008, 00:11:07
Gtnheirby - это еще один непосредственный участник данного проекта, прошу любить и жаловать. Зовут его Саша ...

З.Ы. Саша, надо все-таки выложить в docs.google.com документы, а то так тяжело править.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Описание требований к CRM Ответ #33 : 09 Апреля 2008, 22:05:27



Re: Описание требований к CRM Ответ #34 : 09 Апреля 2008, 22:24:42
Кто хочет править, скажите свои мыла и Саша добавит вас в список участников
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19