Эд, а знаешь какая у меня мысль возникла:
А что если сделать достаточно большой проект но все группой, четко разделив зоны ответственности. Например, делаем ERP, одной группе даем учет склада, другой бухгалтерию, третье что-то еще. Тем самым все студенты будут вовлечены в один процесс и будут/должны обсуждать это между собой. Мне кажется это будет продуктивно. И естественно каждый делает отдельно документ Виденья своей части и т.д., но желательно с учетом требований соседних групп.
Саша, по идее у меня так и есть. Или почти так.
Трудность в том, что нужно грамотно подать некую ERP систему. Или развернуть задачу торговой сети как следует. То есть действительно ты прав, возможно, имеет смысл на первых занятиях подробно рассказать о задаче в целом, разделить ее на связанные блоки.
Хотя именно так и получается сейчас. Т.е. я внутри группы из 6-8 человек предлагаю брать взаимосвязанные задачи.
Сложность использования задач типа учет кадров, учет на складе, бухгалтерия и т.п. заключается в том, что народ некопенгаген во всех этих предметных областях. Хотя не спорю соображают, но соображают по принципу, я я так придумал так и будет. Я говорю, окей, работай, в результате человек закапывается в дебри совершенного отсутствия логичности и связности. Ошибку понял, но процесс упущен, начинается быстрое делание чего-то либо сдать...
Хотя есть команды которые достаточно грамотно работают в нужном направлении.
Вообще у меня возникло желание отказаться от структурных методов как самостоятельной темы обучения.
Хотелось бы переключиться на BPMN, а все структурные нотации тоже использовать, там где это полезно. Например DFD вполне полезно в некоторых случаях.
Я думаю, что мне нужна хорошая постановка задачи. С достаточно точно выделенными проблемами (а их нужно порядка 15-16 - на каждую пару сутдентов).
Ты не хочешь мне помочь в описании бизнес-кейса торговой сети? Можно взять уже наработанное студентами, точно сформулировать процесс, определить явные артефакты, время мидпоинтов. При этом естественно максимально упростить задачу, минимизировать связи между подсистемами, с ориентировать на достаточно простой индивидуальный процесс - кадровые операции, оприходывание товара, анализ продаж, учет продаж, учет склада, инвентаризация и т.п. Т.е. описывать задачу бухучета - это нехорошо в нашем случае. Слишком расширять задачу тоже - нужно учитывать ограничения времени. Задача должна быть компактной, сопряженной с другими задачами. Обязательно расписать проблематику и цели (студентам пока придумывать их сложно).
В качестве примера:
Предположим есть проблемы в кадровом учете. Какие? Скажем директор сети желает получать такие отчеты:
даты рождения сотрудников по месяцам (например дает премию всем кто родился в этом месяце)
сведения об образовании, где получали, и т.п.
кто сколько работает, как хорошо, какие взыскания и поощрения
сколько было приянто, сколько уволено, какдолго не проводилась ротация и т.п.
Проблема в том, что в настоящий момент, при том способе ведения кадровго учета (бумага, вручную или электронные таблицы) - получение всех запросов от директора выливается в целый авральный процесс, при этом никто не уверен, что предоставленная информация полна и верна.
Скажем решение будет таково, что директору предоставят систему из которой он сможет получать все сведения сам, не напрягая сотрудников, их же задаче будет грамотное и своевременное внесение информации.
Ясно, что для создания решения как минимум должен быть организован кадровый учет и своевременный сбор информации - получается, что пока нет этой подсстемы, подсистема директора не имеет смысла. врезультате одна команда может разрабоатывать концепцию и модели кадровго учтеа (прием уволнения перемещение видение личного дела), а вторая состредоточится на реализации подсистемы директора
Просмотр сообщений
Согласитесь, что представленные ранее требования теперь, с концепцией в кармане, допускают намного меньше "детективных" интерпретаций.
