-
Здравствуйте Уважаемые форумчане. Надеюсь на Вашу помощь. Пишу бакалаврскую работу по специальности "Прикладная информатика в экономике" тема работы звучит так: "Автоматизация оформления покупок через веб-портал ОАО Новосибирский Инструментальный Завод". Ездил к начальнику Аналитического отдела завода, чтобы понять что требуется сделать. Была поставлена цель: есть сайт предпрития, необходимо доработать и сделать что-то вроде модуля который бы позволял посетителям выбрать товар, сформировать корзину товаров и оформить заказ, который бы посредством электронной почты отправлялся бы в коммерческий отдел ОАО "НИЗ", где с заказом бы уже работали менеджеры по стандартной схеме, оформление договора, счет-фактур, товарных накладных.
Руководитель ВКРБ поставил передо мной цель: пройти цепочку от функциональной модели к физической посредством объектно-ориентированных CASE-средств. Разработку модуля предполагаем вести по технологии RUP, где важным моментом является на каждом этапе построение диаграмм UML. Так вот, сегодня на ващ суд хочу вынести свою диаграмму USE CASE, которая как мне кажется отражает требования Начальника Аналитического отдела. Честно в UML я практически полный ноль, в университете мы проходили по курсу Разработка и стандартизация но все очень поверхностно, сейчас начинаем изучение в курсе Проектирование Информационных систем, но все равно пока знаний не хватает, пытаюсь читать литературу и вникать во все тонкости.
(http://s52.radikal.ru/i136/0904/0c/e2aacd27efed.png)
-
Граница системы, если я правильно понимаю определение, будет таковой: начиная от формирования заявки на сайте и заканчивая формированием договора и поставкой товара. Наверное так.
Действующие лица (актеры): частное лицо или мелкие предприниматели (акцент будет на них), менеджер по продажам, сам модуль автоматизации заявки, БД коммерческого отдела в котором формируется заявка и все документы необходимые: товарная накладная, счет-фактура, транспортная накладная и центральная складская база (которая передает данные посредством конвертации в локальную БД коммерческого отдела). Необходимо описать ВИ в котором пользователь выбирает товар на сайте, формирует корзину, потом просматривает ее, если надо редактирует, оформляет форму (в которой будет ФИО как связаться адрес и прочая информация от пользователя), потом он отправляет эту форму через модуль, который передает заявку в коммерческий отдел. Менеджер ее проверяет, связывается с тем кто ее оформил, подстверждает ее. Потом начинает формировать договор на поставку, формирует приказ на отгрузку, счет-фактуру, товарную накладную - это в случае если товар есть на складе, в противном случае отказать в заявке. Вот до сюда мне надо построить систему.
Простите что таким примитивным языком изъясняюсь - просто это первый опыт подобной разработки, если так можно сказать.
-
Batak,
Не хочется Вас обижать, но Вы читали те примеры, которые есть в данном разделе? Я там в каждом примере указываю одни и те же ошибки. Прошу прошерстить раздел, посмотреть ошибки и исправить ДВИ в соответствии со сделанными ранее подсказками. Хорошо, если Вы укажите темы в которых смотрели.
-
Постарался разобраться в ДВИ и построить что-то похожее. Сильно не бейте, если опять что-то не так. :'(
(http://s50.radikal.ru/i128/0904/d8/9f55452abb91.png)
-
Ошибки:
1. Сама Система не м.б. Актером
2. Название ВИ должны образовываться от глагола, а у Вас то так то сяк
3. Чем оформить Заказ отличается от Внести данные Заказа?
4. Посмотреть\редактировать\отменить\... Заказ - это CRUD ВИ
Самое главное в ВИ - это его сценарий, после исправления перечисленных ошибок опишите сценарии каждого ВИ и еще раз построити более правильную ДВИ
-
Batak, я бы на вашем месте полностью откалазлся от зависимостей расширения или включения.
1. рано
2. вы их не совсем хорошо понимаете
3. читателю они тоже малопонятны в массе своей
4. ВИ - это не "мужики с яйцами" - это прежде всего текст
5. ДВИ - иллюстрация того, что должна делать систему - стенд с ярлыками - на котором написаны цели
6. Структуризацию следует делать позже, когда общая концепция, гарницы, пользователи и их цели поняты. когда переходим к реализации ВИ
-
Спасибо всем за комментарии.
Bas: 1. Скажите а почему система не выступает актером в этом случае? Когда читал FAQ по USE CASE там написано, что среди распространенных ошибок является отсутствие самой системы или действующего лица? Или она здесь не является актером потому что, она не внешняя?
2. На счет глагольной формы учел.
3. Здесь я просто хотел показать что пользователь формирует заказ на стороне веб-сервера, потом этот заказ поступает в коммерческий отдел, где менеджер уже регистрирует этот заказ в своей СУБД (может просто ВИ неправильно обозвал?)
4. Извините за вопрос, но что такое CRUD?
Galogen: спасибо за замечания, учел.
Пойду думать дальше.
Вопрос относительно CRUD отпал уже нашел информацию на форуме. Тогда возникает другой вопрос: нужно ли эти CRUD ВИ показывать на диаграмме? Если да - то как корректно отобразить?
-
1. Актером м.б. Пользователь или ВНЕШНЯЯ Система. Сама ИС, которую Вы разрабатываете, не м.б. Актером, т.к. мы отражаем ВИ как цель Пользователя по отношению к Системе, т.е. Актеры - это внешние сущности по отношению к самой НАШЕЙ Системе.
3. ВИ не отображают архитектурную особенность Системы, Система воспринимается как нечто целое (во всяком случае пока Вы не поймете азы ВИ и не пойдете дальше изучать их). Поэтому у Вас должно быть 1 ВИ с несколькими участвующими Пользователями
4. CRUD ВИ, например, можно назвать "Управлять Заказом"
-
Вообщем получается так:
Я выделил три актера: СУБД коммерческого отдела (она внешняя система получается у меня), старшего менеджера и пользователя системы автоматизации оформления покупок.
- Цели которые преследует Пользователь при работе с системой: Просмотреть какая есть продукция, сформировать заказ (выбрав нужные позиции товара), просмотреть свой сформированный заказ перед его отправкой, Удалить какие-то позиции из заказа, Добавить новые позиции, Отменить весь заказ
- Цели, которые преследует Менеджер: просмотреть заказ, Оформить заказ, Оформить договор поставки товара
- С разрабатываемой системой взаимодействует внешняя СУБД коммерческого отдела, ее цели: оформить заказ, оформить договор поставки, оформить счет-фактуру, транспортную накладную, товарную накладную
Вот что у меня собственно получилось:
(http://s46.radikal.ru/i111/0904/10/bf2c52f4869f.png)
-
Я не понял про СУБД коммерческого отдела - это что такое? Т.е. у Вас есть Система (и отдельная БД в ней), которую Вы разрабатываете, там хранится каталог продукции и Пользователь делает заказ там, потом этот Заказ передается в другую Систему (СУБД коммерческого отдела) и там уже происходит оформление Заказа и Договора поставки. Так?
-
Да так. Цель работы: разработать систему (модуль) для существующего сайта завода. Этой системой будет управлять СУБД MySQL в которой и будет храниться каталог продукции, пользователь просматривает продукцию и формирует заказ - подобно корзине в электронном магазине. Потом этот заказ отправляется и попадает в коммерческий отдел где менеджер уже его заносит в свою СУБД коммерческого отдела и тама же формирует договор поставки и все необходимые документы.
-
Если Вы не модифицируете Систему коммерческого отдела (я бы слово СУБД заменил на Систему), то зачем на ДВИ Оформление Заказа и Оформление Договора? Пользователь же только Формирует Заявку и она отправляется в Систему коммерческого отдела и зона нашей ответственности заканчивается.
З.Ы. Уже в какой раз убеждаюсь, что Контекстная Д очень помогает в понимании Системы ...
-
Понимаю, что я изрядно уже наверное поднадоел Вам :-[. Но хочу показать свой последний вариант ДВИ. Надеюсь, что он уже будет окончательным.
(http://i019.radikal.ru/0904/aa/abfc519a6b81.png)
-
1. Если Старший Менеджер не смотрит в Вашей Системе Заявку, то его нужно убрать.
2. Сформировать и Отправить Заявку - ЭТО ОДИН ВИ, это одна Цель - Заказать Товар (так даже лучше назвать ВИ), в нем участвует еще Система коммерческого отдела, т.к. в конце Заявка отправляется во внешнюю Систему.
3. Посмотреть Заявку нужно засунуть внутрь CRUD Управлять Заявкой и т.о. будет еще одно объединение двух ВИ.
-
Bas, большое спасибо за терпение и за Вашу помощь в построении диаграммы. Теперь учтя все замечания представляю последний вариант ДВИ.
(http://s45.radikal.ru/i110/0904/fe/f98134afd649.png)
-
Заменить Посмотреть Заявку на Управлять Заявкой и будет все ок.
-
Было:
(http://s52.radikal.ru/i136/0904/0c/e2aacd27efed.png)
Стало:
(http://s45.radikal.ru/i110/0904/fe/f98134afd649.png)
-
комМерческого...
-
И тут возникает вопрос — нафига это всё было нужно, если можно было написать:
Клиент:
- Ознакомиться с каталогом
- Заказать и получить товар
- Узнать статус заявки
?
А написать это всё можно было, проговорив 1 раз с Заказчиком весь сценарий работы Клиента?
-
Я понимаю, что все это было можно так написать и сделать. Понимаете, что в этом я практически полный ноль и поэтому наверное так все и получилось. Рад любым комментариям и учту это все на будущее. Как никак это учебный все-таки проект.
-
И тут возникает вопрос — нафига это всё было нужно, если можно было написать:
Согласно широкомасштабным исследованиям Тони Бьюзена, 95% респодентов разных национальностей, рас и принадлежностей к странам используют в своей работе:
сплошной текст
список
сложный иерархический список
При этом уровень передачи информации, уровень ее восприятия в таком виде остается довольно низким и малоэффективным.
Бьюзн установил, что использование текста в классическом его виде не свойственно способу мышления человека.
Список является линейным,
Список изначально ограничивает развитие мысли
Список не дает охвата
Конечно это не означает, что использовать список не следует, но и говорить, что список лучше и проще, чем например таже диаграмма, не совсем очевидно
Я разделяю мысль Дениса, что ДВИ вряд ли дает что-то, особенно на начальных стадиях, естественнее использовать просто список. А лучше интеллект-карты. Результатом использования интеллект-карты может быть и ДВИ как, скажем, ее подмножество.
Т.е. чем картинка лучше просто текста:
1. картинка дает образ - гештальт, а человек все-таки мыслит образами.
2. картинка дает общий взгляд
3. картинка задействует творческую половину мозга
4. в картинке проще увидет нелогичность или проблемы
5. картинка интереснее чем текст, а значит интерес будет пробуждать и внимание. правда подобного эффекта можно добиться также цветом в тексте...
-
Мы даже с детства, когда решали мат. задачи, делали рисунки, помните два автомобиля едущих друг к другу?!
-
Диаграммы, которые здесь могут быть полезны:
* Контекстная диаграмма бизнеса
* Диаграмма бизнес-процессов VAD
* Концептуальная диаграмма предметной области (без атрибутов)
* Диаграмма содержания деятельности eEPC
* Контекстная диаграмма системы
Далее из диаграммы eEPC напрямую вычленяются Роли и Способы применения, которые можно расписывать по Коберну.
-
1. C Galogen полностью согласен - нас даже по курсу Проектирование Информационных систем - все стадии проектировании (обследование, построение диаграмм UML, написание ТЗ, ИО, ПЗ и так далее) просят изобразить в виде ТСП (Технологическая сеть проектирования), которая сама по себе конечно не является каким-то рисунком, но очень четко позволяет понять что делать, как делать, какие для этого нужны данные, и что мы получаем на выходе.
2. На счет ДВИ, которая у меня получилась в конце - может конечно это нецелесообразно было, но в бакалврской работе у меня есть четкая структура, по которой и требуется изобразить диаграммы и тут уж никуда не деться.
3. Хотелось бы еще задать вопрос. В проектировании своей системы по ВКРБ я использую технологию моделирования RUP - можете посоветовать какие-нить книжки, которые, как Вам кажутся наиболее точно описывают и помогут разобратсья и провести проектирование. Да и времени остается мало на изучение огромных томов :) Буду рад любым высказываниям и предложениям. Заранее спасибо.
-
В проектировании своей системы по ВКРБ я использую технологию моделирования RUP - можете посоветовать какие-нить книжки, которые, как Вам кажутся наиболее точно описывают и помогут разобратсья и провести проектирование. Да и времени остается мало на изучение огромных томов :)
RUP — это не технология моделирования. Это методология организации процесса разработки ПО.
По дисциплине технического (не интерфейсного) проектирования хороша книга Крэга Лармана — «Применение UML2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку».
Только напоминаю, что проектирование должно производиться на основе требований. У вас их пока нет.
Требования на систему автоматизации бизнеса создаются на основе изучения бизнес-процессов — у вас их тоже пока нет.
-
Присоединясь к Денису, могу порекомендовать книгу Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование (http://www.bizbook.ru/book.html?id=6193).
Хотя эта книга не по RUP процессу, но между UP и RUP много общего. К тому же книга написана так, что как раз занятому может помочь быстро понять.
Кроме того, воспользуйтесь ресурсом Wikipedia. Там есть краткое описание RUP-процесса и методологии (http://ru.wikipedia.org/wiki/RUP)
Следует принимать так же тот факт, что будучи фреймвёрком разработки ПО, RUP достаточно адаптивен. Т.е. нужно и можно использовать только то, что Вам действительно требуется.
Если в качестве подхода, Вы избрали разработку по вариантам использования, то здесь можно придерживаться такой концепции (кстати еще вспомнил посмотрите учебник Вендрова. Проектирование ПО для ЭИС):
1.Бизнес-моделирование. Поскольку у Вас несложная в целом система, то его можно свести к созданию Domain Model. Для учебных целей, конечно, можно было бы описать ряд бизнес-процессов. Я, например, со своими бакалаврами делаю примерно так:
глава анализ предметной области - в начале некое самое общее описание объекта автоматизации: организационная структура, выделение основных действующих лиц, описание их задач, описание алгоритмов их задач в виде диаграмм деятельностей. Вполне подойдут и другие нотации. Здесь же описывает модель бизнес-объектов в стиле RUP: человечки, классы сущностей, бизнес-уокеры. Минимум атрибутов, упор на структурные связи и общий контекст
2.далее формулируются требования в виде вариантов использования + дополнительная спецификация - причем тут полная свобода - главное использования принятых стандартов. Не хочешь ВИ, пиши ГОСТ...
3. Далее анализ ВИ, построение аналитических моделей. Т.е. реализация ВИ в виде: аналитической модели классов (начиная с VOPC - т.е. обзор только классов -непосредственных участников с разделением по RUP на граничные(интерфейсные), сущностные(по сути бизнес-объекты или производные от них) и управляющие - хотя бы один на один вариант использования), диаграмм последовательностей. Ясно что всего этого в работе не покажешь, потому просто избирается какой-то наиболее важный ВИ и по нему расписывается, ну и приводится окончательный результат
4. Далее уже принимается решение об архитектуре, классы группируются в пакеты, уточняются, добавляются классы в соответствии с принципами GRASP
5. Реализация включает описание БД и всего с нею связанного (это классы-сущности в основном), а функционирование системы прорабатывается с использованием проектных и программных классов, с привязкой к билиотекам классов и компонентов
Естественно реализовать все это в рамках бакалаврского проекта сложно и нецелесообразно. Потому важно показать наиболее важные артефакты
-
Всем большое спасибо за ссылки и за рекомендации. Можно я буду по ходу выполнения работы задавать вопросы? :)
-
Всем большое спасибо за ссылки и за рекомендации. Можно я буду по ходу выполнения работы задавать вопросы? :)
А кто же вам не позволит :)
-
А первый этап: бизнес-моделирование мы используем для того, чтобы построить модели, отображающие суть дел "как есть" на предприятии? У меня просто проблема - что есть реальное предприятие, реальный отдел "коммерческий отдел", но у меня как таковых нет материалов не по орг. структуре предприятии, не должностных инструкций сотрудников отдела. Как в этом случае поступают? Строят модель так как кажется нужным самому? Просто я на сколько понял, что данных этих нам никто и не предоставит. Перед нами выдвинули задачу, поставили цель, сказали что хотят получить от этой системы - и пустили так сказать в "свободное плавание", хоть головой бейся, но ты должен сделать - получается что все это придется придумывать.
Может тогда поможете немного, как ни как у Вас и практика и опыт есть. :(
-
А первый этап: бизнес-моделирование мы используем для того, чтобы построить модели, отображающие суть дел "как есть" на предприятии? У меня просто проблема - что есть реальное предприятие, реальный отдел "коммерческий отдел", но у меня как таковых нет материалов не по орг. структуре предприятии, не должностных инструкций сотрудников отдела. Как в этом случае поступают? Строят модель так как кажется нужным самому?
Есть стандартные процедуры проведения обследования для построения модели бизнес-процессов — фотография рабочего дня, изучение регламентов, внешних нормативных документов, проведение опросов, интервью.
Просто я на сколько понял, что данных этих нам никто и не предоставит. Перед нами выдвинули задачу, поставили цель, сказали что хотят получить от этой системы - и пустили так сказать в "свободное плавание", хоть головой бейся, но ты должен сделать - получается что все это придется придумывать.
Может тогда поможете немного, как ни как у Вас и практика и опыт есть. :(
Накидайте модель процессов в неформальном виде, уточните её правильность у постановщика. Обычно люди гораздо больше информации выдают, когда видят хоть что-то, тем более неправильное, чем когда к ним приходят с чистым листом.
-
Накидайте модель процессов в неформальном виде, уточните её правильность у постановщика. Обычно люди гораздо больше информации выдают, когда видят хоть что-то, тем более неправильное, чем когда к ним приходят с чистым листом.
Соглашусь с Денисом.
Но только вы решите сначала - какую модель вы будете показывать заказчику - as is или to be? Учитывая что для to be у вас пока мало знаний о предметной области - лучше начать с as is, причем сразу планируйте потратить много времени на ее уточнение.
И еще - хорошо бы после того как получите согласованное с заказчиком представление того, как сейчас все происходит, задать заказчику вопрос - а почему надо менять? Какие выгоды будут от нового процесса, какие ветки на старой диаграмме исчезнут, какие "узкие" места "разошьются"? Вам может показаться, что вы и сами знаете ответ на этот вопрос, но лучше получить его от заказчика, причем не подсказывая ему свои мысли.
-
Смотрите, Ваша тема "Автоматизация оформления покупок через веб-портал ОАО Новосибирский Инструментальный Завод". Есть некое описание этого процесса или то, что предполагается получит от этого.
Сразу возникает вопрос:
1. Является ли ОАО Новосибирский Инструментальный Завод новатором в этой области?
2. Каким образом именно сейчас осущестувляется оформление каких-либо покупок?
3. А какие виды покупок различают, в чем их особенности?
4. Кто оформляет покупку сейчас? Как он это делает? Кто еще вовлечен в процесс покупки?
5. Что нужно, чтобы осуществить покупку?
6. Как клиент узнает о предмете покупки?
7. Что собственно продает ОАО Новосибирский Инструментальный Завод?
8. Чем это отличается от того, что например продает книжный магазин?
9. Почему возникла потребность создания интернет-площадки для продажи?
10. Кто является покупателем-клиентом завода?
-
Ездил к начальнику Аналитического отдела завода, чтобы понять что требуется сделать. Была поставлена цель: есть сайт предпрития, необходимо доработать и сделать что-то вроде модуля который бы позволял посетителям выбрать товар, сформировать корзину товаров и оформить заказ, который бы посредством электронной почты отправлялся бы в коммерческий отдел ОАО "НИЗ", где с заказом бы уже работали менеджеры по стандартной схеме, оформление договора, счет-фактур, товарных накладных.
Действующие лица (актеры): частное лицо или мелкие предприниматели (акцент будет на них), менеджер по продажам, сам модуль автоматизации заявки, БД коммерческого отдела в котором формируется заявка и все документы необходимые: товарная накладная, счет-фактура, транспортная накладная и центральная складская база (которая передает данные посредством конвертации в локальную БД коммерческого отдела). Необходимо описать ВИ в котором пользователь выбирает товар на сайте, формирует корзину, потом просматривает ее, если надо редактирует, оформляет форму (в которой будет ФИО как связаться адрес и прочая информация от пользователя), потом он отправляет эту форму через модуль, который передает заявку в коммерческий отдел. Менеджер ее проверяет, связывается с тем кто ее оформил, подстверждает ее. Потом начинает формировать договор на поставку, формирует приказ на отгрузку, счет-фактуру, товарную накладную - это в случае если товар есть на складе, в противном случае отказать в заявке.
1. Организационная структура
коммерческий отдел ОАО "НИЗ"
менеджеры
2. Что делает менеджер:
1. работает с заказаом по стандартной схеме - это что такое?
2. получает заявку, свзяывает с автором, подтверждает ее, проверяет наличие товара на складе, пускает в ход
3. оформляет договор
4. формирует приказ на отгрузку - приказ кому? самому себе?
5. формирует счет-фактуру - кому покупателю?
6. формирует товарные накладные - кому?
3. что используем:
Есть База данных коммерческого отдела - как к ней получают доступ, что из нее берется? Является ли эта база частичным клоном центральной базы? И следовательно не будет ли БД ком отдела основой вашего приложения?
4. в целом
клиент выбирает товар на сайте: каким образом, что ему доступно, что за информация о товаре размещена? почему нельзя сразу узнать об отсутствии товара на складе? кто заполняет и ведет каталог товаров на сайте, как связан каталог с базой данных склада?
клиент формирует корзину - может ли корзина сохранятся между сеансами?
клиент оформляет заказ заполняя некую форму
после сохранения заказа он отправляется менеджеру на мыло? со всем его содержимым?
менеджер проверяет заявкуи и в путь выше описано.
А что если у менеджера сотни в день таких заявок, как он узнает отмечает что заявка им прочитана и по ней сделан ход? сколько времени нужно для исполнения заявки, какое количество менеджеров работает, как между ними распределяются заявки и т.п.
Поскольку Вашей задачей является создание модули принятиязаявки, то очевидно нужно сосредоточить внимание:
1. на каталоге товаров
2. на способах формирования корзины
3. на оформлении заказ-заявки
4. вход и регистрация клиента
Остальное как я понимаю за кадром
Вам похожеоргструктура почти и не нужна :)
-
Ответы на вопросы предыдущего поста:
1. Да является новаторов, если учесть, что создается интернет-площадка для продажи - это новое.
2. Оформление покупок осуществляется через размещение заказов в коммерческом отделе предприятия - далее все по стандартной форме: резервирование товара на складе, получение предоплаты, доставка и отгрузка товара заказчику, получение всей суммы, закрытие заявки.
3. В основном сейчас оптовые виды покупок. Работают с крупными оптовыми заказчиками, есть свой розничный магазин при заводе.
4. Оформление покупок производит менеджер коммерческого отдела, он же формирует всю документацию: товарная накладная, счет-фактура, договора а так же приказа на отгрузку (это внутренний документ и поступает он на склад, дублирует во многом счет-фактуру)
5. Разместить заказ - сейчас в основном работают с крупными заказами (начиная от 300 000 рублей и выше), мелкие рассматриваются в последнюю очередь.
7. Вообщем всякие инструменты :) Головки, слесарные наборы, ключи гаечные, ключи разводные, шарниры, патроны сверильные, кусачки, пласкогубцы, зубила, стамески, тиски и прочее.
8. Ну может тем, что вся продукция выпускается по ГОСТам? И имеет высокое качество.
9. Потребность в создании Интернет-площадки возникла, потому что сейчас завод работает с крупными оптовиками, но при этом теряет мелких оптовиков, частных лиц и мелких предпринимателей (пускай их и немного - но все вместе они образуют "большой пласт" потенциальных потребителей). Таким образом они хотят с помощью Интернет-площадки предоставить возможность этой категории потребителей просмотреть продукцию и сформировать свой заказ.
10. Ну как я писал выше это крупные оптовые фирмы, которые уже потом поставляют продукцию дальше по региону и по России.
Тут и возникает вопрос: про организационную структуру. Следует описывать организационную структуру отдела или всего предприятия, или лишь отделов которые в какой-то мере задействованы во всей схеме оформления заказа-продажи?
И что самое интересное: при разговоре с Гусевым (начальник АСУ ОАО НИЗ) он говорил о том, что заказы должны поступать на e-mail? Хорошее конечно требования, но действительно как быть если этих заявок будет сто? Двести? Это придется же сколько обрабатывать заявки?
В конце своей работы, как мне теперь сказали, я должен получить все таки программную реализацию, но как я понимаю для завода дать лишь рекомендации по поводу этого. Потому что сейчас у них никто не занимается ни сайтом, который есть, а уж тем более никто не будет браться за заполнение каталогов и их ведение. Вот такой парадокс получается :)
-
1. Да является новаторов, если учесть, что создается интернет-площадка для продажи - это новое.
Я понял вопрос Эдуарда по-другому. Для меня вопрос прозвучал так - правда ли, что ни у какого другого (похожего) завода нет такой площадки? Если да, то этот завод - новатор. Иначе - нет.
2. Оформление покупок осуществляется через размещение заказов в коммерческом отделе предприятия - далее все по стандартной форме: резервирование товара на складе, получение предоплаты, доставка и отгрузка товара заказчику, получение всей суммы, закрытие заявки.
А как размещаются заказы? Что поступает в коммерческий отдел предприятия - телефонный звонок, письмо по почте, факс? Есть ли какая-то форма которую надо заполнить для того, чтобы заказ приняли в обработку? Что содержится в этой форме, если она есть? Если ее нет - то какую вообще информацию предоставляет покупатель? Кроме списка товара и его количества, это я думаю очевидно, представляет ли покупатель свои реквизиты? Если да, то что именно - уставные документы, их копии, заверенные или нет? Выписку из банка? Покупатель может быть физическим лицом? А индивидуальным предпринимателем? А лицом, занимающимся частной практикой? Может быть покупатель нерезидентом? Если да, то какие документы от него требуются? На каком этапе происходит сбор данной информации, если она нужна? На этапе заявки на покупку товара или при оформлении покупки (п.4)?
3. В основном сейчас оптовые виды покупок. Работают с крупными оптовыми заказчиками, есть свой розничный магазин при заводе.
Планируется ли сохранить такой порядок? Будет ли Интернет-площадка работать с розничными покупателями?
4. Оформление покупок производит менеджер коммерческого отдела, он же формирует всю документацию: товарная накладная, счет-фактура, договора а так же приказа на отгрузку (это внутренний документ и поступает он на склад, дублирует во многом счет-фактуру)
Это данному менеджеру должен поступать заказ с интернет-площадки? И если да, то такой менеджер один или нет? Должны ли заказы на разные группы товаров поступать различным менеджерам? Как правило менеджеры по продажам имеют бонусы от суммы своих продаж - кто же из них будет тогда получать заказы с сайта и по какому алгоритму должны распределяться эти заказы?
7. Вообщем всякие инструменты :) Головки, слесарные наборы, ключи гаечные, ключи разводные, шарниры, патроны сверильные, кусачки, пласкогубцы, зубила, стамески, тиски и прочее.
Как будут группироваться товары на сайте? Планируется ли дать пользователю сайта возможность сохранять и отслеживать свои заказы, а также создавать на их основе шаблоны - чтобы не заполнять каждый раз простыню на товарных 100 позиций? Если да, то как поступать в случае изменения номенклатуры в шаблоне?
8. Ну может тем, что вся продукция выпускается по ГОСТам? И имеет высокое качество.
Хм.. Ну вот, допустим, изменяется ли общая цена в зависимости от совокупного заказанного веса товара? Возможно ли заказать товар, которого еще нет на складе готовой продукции? Требуется ли учитывать данные параметры при составлении заказа на сайте, нужно ли показывать пользователю эти данные, если учитывать то как именно?
9. Потребность в создании Интернет-площадки возникла, потому что сейчас завод работает с крупными оптовиками, но при этом теряет мелких оптовиков, частных лиц и мелких предпринимателей (пускай их и немного - но все вместе они образуют "большой пласт" потенциальных потребителей). Таким образом они хотят с помощью Интернет-площадки предоставить возможность этой категории потребителей просмотреть продукцию и сформировать свой заказ.
Оценивал ли кто-нибудь размер этого "потерянного" кластера покупателей в денежном отношении? Может ли быть такое, что овчина не стоит выделки? Есть ли достаточно сотрудников, чтобы обрабатывать заказы данных покупателей, тем паче, что вы писали, что работают, в основном, с крупными заказами (п.5)? Не получится ли так, что этот ворох мелких заказов останется без ответа и это в будущем вызовет негативное отношение потенциальных заказчиков (я им заказ сформировал, а они даже не почесались!)?
10. Ну как я писал выше это крупные оптовые фирмы, которые уже потом поставляют продукцию дальше по региону и по России.
Может быть лучше тогда на них и сосредоточиться?
Тут и возникает вопрос: про организационную структуру. Следует описывать организационную структуру отдела или всего предприятия, или лишь отделов которые в какой-то мере задействованы во всей схеме оформления заказа-продажи?
По-моему мнению, лучше описывать те отделы, которые вовлечены в процесс.
И что самое интересное: при разговоре с Гусевым (начальник АСУ ОАО НИЗ) он говорил о том, что заказы должны поступать на e-mail? Хорошее конечно требования, но действительно как быть если этих заявок будет сто? Двести? Это придется же сколько обрабатывать заявки?
Задайте этот вопрос ему. Предложите несколько вариантов решений.
В конце своей работы, как мне теперь сказали, я должен получить все таки программную реализацию, но как я понимаю для завода дать лишь рекомендации по поводу этого. Потому что сейчас у них никто не занимается ни сайтом, который есть, а уж тем более никто не будет браться за заполнение каталогов и их ведение. Вот такой парадокс получается :)
Судя по всему, вам дали "висячую" работу, которая никому не нужна на данном этапе. Сделаете - хорошо, не сделаете - ничего страшного :)
-
Я понял вопрос Эдуарда по-другому. Для меня вопрос прозвучал так - правда ли, что ни у какого другого (похожего) завода нет такой площадки? Если да, то этот завод - новатор. Иначе - нет.
+1 Я бы даже расширил ситуацию. Является ли завод вообще первым в мире, кто решил продавать что-то через интернет? Это бы вопрос с подковыркой. Меня часто удивляют студенты и не только, которые сразу начинают изобретать очередной велосипед. Причем гораздо худший, чем уже есть.
Насколько я понимаю, Вы, Batak, уже вполне определись с тем, что будете делать. Не имеет ли смысл посмотреть вокруг, а чего понаделали ваши соседи по планете :)