Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: natterru от 07 Августа 2007, 16:26:34
-
Тема CRM достаточно популярная. Ближайшие 3 месяца буду анализировать процессы в этой концепции или философии. Сначала разбираясь с классическими CRM, потом применять это к продажам услуг рекламы.
Мне понравилась online-CRM, ссылку нашел в ветке мини-CRM http://crm.zoho.com (http://crm.zoho.com)
Не плохо всё документировано, документацию скачал... читаю. Еще есть интерес с точки зрения архитектуры к MS CRM, у них скоро 4-я версия выходит, кое-какие материалы есть по 3-й версии. Кто что думает по этому поводу готов выслушать.
-
Valery! Если честно, не понял в чем вопрос? Почему тема размещена в "Примерах"?
-
потому что планирую здесь размещать ВИ в терминах CRM и расширения для моего домена. Может у кого то что то тоже есть по этой теме.
-
потому что планирую здесь размещать ВИ в терминах CRM и расширения для моего домена. Может у кого то что то тоже есть по этой теме.
Т.е. пока вопроса нет, а есть только предложение, анонс так сказать?
-
Да анонс и поиск заинтересованной аудитории. А то все системы CRM или никакущие как 1С или дорогущие как Oracle Siebel, SAP или MS CRM. Среднему предприятию поднять такую CRM сложно, лицензии (коробка) от 20 000 до 50 000$ и настройка под веритикаль бизнеса от 200 000 до 500 000$. Вот и есть работа у отдела программирования сделать не просто торговую систему, но и всякие фишки типа автоматизации процесса продаж(реализация потенциальной сделки: интерес, заказ, счет, завершение сделки) + удобный поиск, назначение задач, легкость освоения.
Определять бизнес-политику на основании установленных процессов продажи.
• Обеспечивать выполнение обязательств по отношению к клиенту.
• Автоматически информировать руководителей о возникших проблемах.
• Распределять объем работы для рабочих групп и территорий.
• Управлять ключевыми бизнес-политиками и процедурами.
• Обеспечивать согласованное выполнение процесса обслуживания клиента.
Процесс продаж. Это набор последовательных шагов, которые проходит возможная сделка. Процесс продаж используется только для возможных сделок. Процессы бизнес-правил и процессы продаж могут применяться системой автоматически или пользователем вручную.
И т.д...
-
А если посмотреть в сторону свободных CRM типа SugarCRM? http://www.sugarcrm.com/
-
Так. Народ. Ща Боатман придет и всех порвет.... Описываем цели, проблемы, аналогичные решения, и чем наше будет лучше.
-
Изходя из хилого бюджета до 30 000 евро, это будет просто торговая система с элементами ЦРМ. Ибо нормальные вещи дорого стоят, а дешевого нам не надо. Это будет новая система. Юзвери говорят, покажи чего есть из последних технологий. Я говорю а чего ты хошь? Конечно пишу концепцию, цели, задачи.
-
Вопрос в другом: почему, имея пользователей и их проблемы под боком сразу начинаем с выбора парадигмы построения бизнеса?
Это что такое??
-
исходя из определения "что парадигма - это первообраз, образец по которому что-то строится" -- "парадигма построения бизнеса" ... это что-то из работ Адама Смита? :-)
-
Привет всем архитекторвующим!
Вот не знаю как обозвать сущность фирма-предприятие. В наиболее известных CRM используется значение ACCOUNT для этого, но ACCOUNT - это и набор данных для регистрации пользователей в системе. Тем более я демаю CRM для рекламного бизнеса, а там это слово именно и обозначает клиента-организацию. Кто сталкивался с этим? Решил ролевую сущность обозначающую права доступа к системе и элементам интерфейса назвать ACCESS.
-
НЕ совсем понял, но мне кажется больше подойдет UserAccess
-
Привет всем архитекторвующим!
Вот не знаю как обозвать сущность фирма-предприятие. В наиболее известных CRM используется значение ACCOUNT для этого, но ACCOUNT - это и набор данных для регистрации пользователей в системе. Тем более я демаю CRM для рекламного бизнеса, а там это слово именно и обозначает клиента-организацию. Кто сталкивался с этим? Решил ролевую сущность обозначающую права доступа к системе и элементам интерфейса назвать ACCESS.
CUSTOMER
CLIENT
advertising account ["xdvqtaIzINq'kaVnt]
заказчик, клиент рекламного агентства, рекламодатель
PATRON - 1) (постоянный) покупатель, клиент; постоянный посетитель
CONSUMER
PROSPECT 3. предполагаемый покупатель, клиент, подписчик, кандидат и т. п.
ACCOUNT 2) (любой) заказчик, покупатель, клиент
-
Ну собственно, продолжаем.
Начал писать Видение для одной организации. Читаем и критикуем.
-
Саша, а что собственно обсуждать? Видения практически нет. Идея бизнеса отсутсвует. Известно лишь то, что есть какие-то проблемы с бумажками. Однако строго они не определены. Неясны и причины этих проблем. То ли это отсуствие исполнительской дисциплины, толи сожность ее контроля, то ли потери возникающие при рутинном ведении поцесса.
По моему скромному убеждению, проблема должна иметь количественные выражения. Скажем есть проблема составления отчета. Однако отчет готовится только один раз в год. Хотя задача в целом актуальна и трудоемка, тем неменее ее острота не так велика.
При работе с документами сразу возникает вопрос, а как с ним работают сейчас? Если документы обрабатываются в бумажном виде, то будет ли учет их через электронную систему благом? Или же просто будет дублировать процедуру ручной обработки.
Поясню: предположим некому менеджеру поступают заявки (сколько с какой частотой?). в его обязанности - посмотреть заявку, наложить резолючию и передать (назначить) исполнителю.
Предположим, менеджер ежедневно получает в начале рабочего дня стопку таких заявок и в течение 2 часов просматривает их и пишет резолюцию. Папка передается в канцелярию и секретарь раскладывает задания по исполнителям.
Исполнители неким образом получают эту информациюи начинают исполнять.
Мы внедряем систему учета документооборота и отслеживания выполнения поручений. Как это будет выглядеть?
Секретарь канцелярии будет вводить каким-то образом документы в систему и указывать менеджера?
Менеджер на своем рабочем столе види список поступающих задач, обрабатывает их и назначает резолюцию.
При этом менеджер должен определить статус работы, тип ее и т.п.
Каждый исполнитель получает каждое утро свой список задач и начинает исполнять их или указывает чтоне может исполнить задачу по тем или иным причинам
Менеджер видитотказ от исполнения и принимает решения по разрешению конфликта.
В данной ситуации безусловно менеджер видит всю картину в целом, знает в каком состоянии и кто выполняет задачу, знает и видит сроки выполнения и т.п.
Однако будет ли удобно менеджеру читать документы прикрепленные к задаче в электронном виде?
Кроме того, кто будет вводить такой документ?
Не окажется ли это намного сложнее, чем простой просмотр документов менеждером.
Не возникает ли потребность вводить еще одно звено в общий поток работы - скажем поток кординатора, т.е. канцелярия просматривает документы и фиксирует их, менеджер получает бумажные копии и распределяет их, некое промежуточное звено от имени менеджера вводит документы и задачи в систему.
Далее сама система должна быть как я понимаю интегрирована с отделом кадров - чтобы получать сведения о сотрудниках.
Я вижу несравненное удобство от введения этой системы на нижнем уровне, но есть проблемы на верхнем. то есть на уровне менеждера, будет ли ему нравится другой стиль работы?
-
Эд, ну ты прям хочешь все и сразу. Это только небольшое начало. То, что я смог написать за час после интервью. Естественно дальше будут описаны все БП и пройдясь еще раз по ним дополню потребности и проблемы, определены риски.
-
Может для начал было бы полезнее выложить само интервью? и уже после интервью переход к видению?
Кроме того мне кажется не стоит видение утяжелять руповским шаблоном
Он же не стандрат, а рекомендация.
может сначал описать саму формулу проблемы. видение как мне кажется есть результат анализа проблемы.
Согласен с цикличностью, согласен с неполнотой.
Судя из контекста
КИС CRM-Интегратор предназначена для автоматизации деятельности компании ООО "Пирожок" в части обработки заявок клиентов, распределения обязанностей внутри компании и контроля прохождения документов. Данная компания специализируется на продаже видеооборудовании и услуг связанных с его установкой и обслуживанием.
обработка заявок клиентов
рапределение обязанностей
контроль прохождения документов
Далее
2.1.1 Уменьшение времени работы с документами за счет уменьшения времени на коммуникацию, возможности работать не зависимо от конкретного человека и избавления от бумажных документов
Предполагается ли, что все документы организации от ныне будут электронными. Насколько это возможно? Как к этому все отнесутся, что делать если будет поступать и поток бумажных документов и возможно не маленький. И каких именно бумажных документов?
2.1.5 Уменьшение времени, требуемое на предоставление Бонусов для работников за счет консолидирования информации
нихт фирштейн зи
2.2.2 Менеджеры забывают закупать оборудование
что им за это бывает?
-
Может для начал было бы полезнее выложить само интервью? и уже после интервью переход к видению?
Так его надо печатать. Не охота. Выкладываю сырые БП, описанные руководством Компании.
Кроме того мне кажется не стоит видение утяжелять руповским шаблоном
Выкинем все что не нужно. Это же просто шаблон. Я его обычно беру за основу всегда.
может сначал описать саму формулу проблемы. видение как мне кажется есть результат анализа проблемы.
Если будет время, то напишу. М.б. привлеку руководство компании сюда.
2.1.1 Уменьшение времени работы с документами за счет уменьшения времени на коммуникацию, возможности работать не зависимо от конкретного человека и избавления от бумажных документов
Предполагается ли, что все документы организации от ныне будут электронными. Насколько это возможно? Как к этому все отнесутся, что делать если будет поступать и поток бумажных документов и возможно не маленький. И каких именно бумажных документов?
Именно. одна из целей/задач - избавиться от бумажек и блокнотов на столах
2.1.5 Уменьшение времени, требуемое на предоставление Бонусов для работников за счет консолидирования информации
нихт фирштейн зи
Ну это я написал, чтобы не забыть. Со временем м.б. уйдет. Просто Инженер начисляет бонусы монтажникам, вот чтобы их начислять - это не контролируемый и долгий процесс.
2.2.2 Менеджеры забывают закупать оборудование
что им за это бывает?
По башке, но это не суть. Что бывает Руководству - вот это хуже.
-
1. Первое что бросилось в глаза, прямо в содержании -- перевод термина stakehoihlder как "совладелец" ... думаю что лучше будет как "заинтересованное лицо"
2. Это конечно up to you, но по мне, "деловые преимущества", хорошо что хоть не "деловые процессы" :-) ... ну не поворачивается у меня язык так называть ... я бы предпочел "преимущества для бизнеса".
3. Я обычно в Vision выделяю отдельно в виде раздела, или подраздела "Основные бизнес-цели", или просто "Цели создания системы".
4. В качестве цели (но это просто на мой извращенный вкус :-)), я бы сказал не "уменьшение времени работы с документами" ... а "сокращение времени обработки (создания) документов" ... что-то в этом духе. И вообще, можно свернуть цели в более краткую формулировку, типа "Сокращение времени на обработку документации", можно добавить за счет чего (но лучше за счет чего -- в п. 3.6 или в п. 4.2) "Повышение количества выполненных в срок Заявок", ну и про бонусы тоже можно ... но на мой взгляд тут нужно будет сказать еще про то, что повышается "точность расчета бонусов" ...
5. Далее ... "2.2.1 Много бумажных документов. Желание избавиться от бумажек на столах и ежедневников." .. это не есть КОРНЕВАЯ проблема. Нужно найти the problem, behind the problem. "Много бумажных документов" -- звучит как следствие некой другой проблемы. Задача -- как раз выявить корневую проблему, задавая вопрос "Почему много бумаг?"
Это так, навскидку ... :-)
-
Юрий, можешь вложить шаблон или пример Vision, который ты обычно используешь?
-
Вот руководство компании нашло пять причин в интернете, по которым компании устанавливают CRM и ERP системы. Они утверждают, что все эти причины имеют место быть в их компании. Т.е. это и есть те причины, по которым они хотят интегрировать в их бизнес CRM:
1. Интегрировать финансовую информацию. Когда руководитель пытается оценить работу компании, он может увидеть много разных «версий правды». Финансовый отдел предоставляет одну версию отчёта о доходах, отдел продаж – другую. Остальные подразделения могут показывать свои варианты того, каков их вклад в бизнес. CRM-система создает один окончательный вариант правды, который не может никем оспариваться, поскольку все используют одну систему.
2. Интегрировать информацию о заказах. В CRM-системе заказ проживает всю свою жизнь – от момента появления во фронт-офисе, до той минуты, когда товар отгружается клиенту, а бухгалтерия выписывает ему счет. Имея информацию в одной системе, а не «размазанной» по множеству различных приложений, компании легче отслеживать заказ и координировать производство, складирование и отгрузку по всем подразделениям одновременно.
3. Стандартизировать и ускорить процесс производства. Производственные компании, особенно обладающие аппетитом приобретать и сливаться, часто обнаруживают, что многочисленные подразделения компании делают одно и то же, используя разные методы и разные компьютерные системы. CRM-системы приходят со стандартными методами автоматизации определенных шагов производственного процесса. Стандартизация этих процессов и использование единой интегрированной системы экономит время, увеличивает производительность и уменьшает головную боль.
4. Уменьшить складские запасы. CRM-системы способствуют тому, что производственный процесс протекает более гладко, улучшается процесс исполнения заказа внутри компании. Компания теперь может запасать меньше сырья, необходимого для производства продукта, и хранить меньше готовой продукции на складах. Для того, чтобы радикально улучшить всю цепочку поставок, вам может потребоваться специальный модуль SCM (Supply Chain Management – управление цепочками поставок), который сегодня входит в стандартную конфигурацию большинства ERP-систем.
5. Стандартизировать информацию по персоналу. В компаниях с большим количеством различных бизнес-единиц отделы кадров часто не имеют единой унифицированной методики отслеживания рабочего времени персонала и работы с ним. Это положение может исправить CRM. Спеша сделать это, компании часто упускают из виду, что CRM дает не более чем общее представление того, как некая типичная компания делает свой бизнес. Реальность же намного сложнее, и каждая отрасль имеет «фишки», делающие бизнес компании уникальным.
-
Юрий, можешь вложить шаблон или пример Vision, который ты обычно используешь?
Выложить не проблема, найти нужно наиболее приличный перевод шаблона ... Не забыть бы :-)
-
Предложу Participant, если речь идет об учаснике, у которого может быть много пользователей в системе со своими логинами-доступами-ролью
-
Дописал Видение и Глоссарий. Смотрим, даем замечания.
-
Нарисовал ДБО и ДСВИ, смотрим комментируем.
Сама модель, тоже во вложении.
-
Для полной картины еще выкладываю БП от заказчиков
-
Александр, по ДСВИ есть несколько вопросов.
1) Актеры, отличные от Пользователя, инициируют ВИ "Войти в Систему"? Т.е. необходимо ли Секретарю, РМ и др. аутентифицироваться и авторизироваться в системе? Или они являются "потомками" актера Пользователь, но это не указано на диаграмме?
2) Подразумевается ли дальнейшее расширение ДСВИ? Если нет, тогда не совсем ясно как управлять, например, справочником, учетными записями и др? Возможно применение паттерна CRUD, который был описан Эдуардом http://www.uml2.ru/forum/index.php?topic=628.0 (http://www.uml2.ru/forum/index.php?topic=628.0) ?
3) Актеры РП и Пользователь оба инициируют ВИ "Назначить задание"? Другими словами и РП и Пользователь могут назначать задания кому-то (не понятно кому) или РП назначает задания пользователю (тогда необходимо изобразить направленную ассоциацию на пользователя)?
-
Виталий,
Все верно, СДВИ еще не полная. Я ее "состряпал" за 15 мин, и не учел много чего. Она будет дополняться. И в первую очередь я опишу их в виде сценарии ВИ, чтобы не было двух мнений.
Теперь ответы на ваши вопросы:
1. Да, добавлю диаграмму иерархии ролей
2. Как раз патерн CRUD тут и подразумевался
3. Тут сценарий немного другой - РП назначен задания любому пользователю, т.е. эти две роли участвуют в ВИ "Назначить задание"
-
Последнее обновление. Скоро все документы будут перемещены в docs.google.com, чтобы удобнее было смотреть и править. К проекту подсоединился еще один аналитик, теперь все пойдет быстрее.
-
Сколько то лет назад делал продукт CRM - были и Vision по руповскому шаблону и достаточно масштабная модель по UML шаблонам. http://crm.oblik.com.ua/ Но в общий доступ выложить не просите :-)
Архитектор того проекта собрал небольшую компанию спецов и сейчас массово штампует Web Based CRM системы. С готовым и быстрым движком получается дешево и сердито по крайней мере эффективнее чем размер котоый удовлетворит всех :-) (ИМХО за 30 000 евро имхо лучше разарботку с нуля не затявать У меня в первом релизе было порядка 30 сценариев и этого было мало и еще по тем временам при очень некислой эффективности разарботки это стоило больше 30 k у.е. ) ...
p.s. Ссылку на google docs в студию :-)
-
Замечания по документации проекта и содержанию
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.
Нет общей картины, бизнес-плана...
-
По-моему совсем было бы не лишним предоставить документ требования
(запросы) заказчика или оценка целевой организации. Это дает более четкое
ощущение контекста и понимание проблематики
Верно, но заказчик очень занятой человек. Пока получается - я его слепила
из того что было. Но заказчик, я думаю будет еще предоставлять информацию.
отсутствие консолидирования информации, сложный доступ к хранимой
информации, слабый контроль исполнения заявок
Выявилась основная проблема :)
Далее напомню, что CRM классифицируется на оперативный, аналитический и
коллаборационный
Да, система скорее всего будет оперативной с элементами аналитики.
(Извиняюсь, но сам первый раз слышу о классификации црм, надо
образовываться).
Ошибки по тексту поправяться, просто все писалось в спешке.
Описание ВИ, думаю надо принять, с поправками Коберна (вот, и его надо почитать).
А бизнес процессы попробовал представить в Activity.
Итого:
выкладываю архив с изменениями (орфографию не поправили)
жду предложений по дальнейшим действиям (все таки хочется сделать что
нибудь грамотное)
-
Gtnheirby - это еще один непосредственный участник данного проекта, прошу любить и жаловать. Зовут его Саша ...
З.Ы. Саша, надо все-таки выложить в docs.google.com документы, а то так тяжело править.
-
Собственно ссылки:
http://docs.google.com/Doc?docid=dfxwsz8z_3c7gzgtcc&hl=en
http://docs.google.com/Doc?docid=dfxwsz8z_10djwkpzxz&hl=en
http://docs.google.com/Doc?docid=dfxwsz8z_11gktdvtdx&hl=en
http://docs.google.com/Doc?docid=dfxwsz8z_7x49kbtg8&hl=en
-
Кто хочет править, скажите свои мыла и Саша добавит вас в список участников