76

Обучение / Re: Дисциплина "Системная инженерия"

« : 18 Декабря 2011, 11:53:49 »

Альтернатив несколько, хочется выбрать оптимальную...

да-да, самую оптимальную :о)))
давай-ка начнем с критериев оптимальности или хотя бы с того, что должен суметь сделать выпускник, как специалист по ИС?

77

Обучение / Re: Дисциплина "Системная инженерия"

« : 18 Декабря 2011, 00:44:54 »

такую смотрел? http://win-web.ru/itbooks/open/sommervil_ingprogr.html

78

Методологии / Re: Методология PDM-систем и управление проектами на промышленном предприятии

« : 17 Декабря 2011, 23:29:52 »

еще вопросы появились?
:о))

79

Методологии / Re: Методология PDM-систем и управление проектами на промышленном предприятии

« : 17 Декабря 2011, 21:04:08 »

Добрый день,

пусть немного позже, но встряну, т.к. опыт по внедрению PDM/PLM таки имеется. Более того, непосредственно столкнулся с двумя производителями (Dassault и PTC) и, соответственно, их PDM-системами и CAD-системами. CAM/CAE в проекте не рассматривали, но если что, то можно и их присобачить...
Кстати, дело частично (пилот) проходило в Самаре :о)))

Из прочитанного выше у меня не сложилось понимания, что понимание автора топика обладает по меньшей мере связностью. Поэтому толковые мысли Tinner'а, прошедшего определенные горнила, не находят четко выраженного отклика.

Что тут можно посоветовать?
во-первых, учить матчасть... причем долго и упорно...
во-вторых, есть МАССА тематических сайтов, где можно многое почерпнуть. например, www.johnstark.com - это из импортного, а теперь отечественный производитель - тульский токарев, он же ТТ, сегодня один, извини, очень быстро разбирают isicad.ru . в инете можно найти кучу форумов по этой тематике. также есть куча тематических мероприятий, которые в т.ч. проводят упомянутые компании. но штука в том, что сами по себе они не дадут просветления сознания - нужно самому сначала допереть.
в-третьих, у того же джона старка на сайте должна быть отличная книжка на языке вероятного противника - Introducing to PDM. Очень рекомендую почитать. Там нет ничего заумного, но очень хорошо определены ключевые моменты и расставлены акценты. Есть там книжка и про PLM, но она в тот период была за деньги, поэтому я ее не скачал, и потом, она большая и тяжелая (в физическом смысле)

К сожалению, не прозвучало выше, поэтому скажу, что основное для чего предназначены эти системы - для автоматизации технологии проектирования, которая на очень многих наших предприятиях недалеко ушла от времен царя Гороха. Есть приятные исключения, но они пока исключения, например, завод электропульт в питере (или где-то поблизости). Так вот, технология проектирования является составной частью культуры производства. Если Вы оглянетесь на Вашем предприятии, то легко определите, какая у вас технология проектирования. Кстати, технология проектирования, как и бизнес процессы, есть всегда. Другое дело, какая она и какова ее эффективность? Однако наличие технологии не означает, что ее можно натянуть на систему или, наоборот, натянуть систему на технологию. Такой вот парадокс. Причина - в принципиально разных парадигмах, которые используют западные производители (включая производителей софта для проектирования) и наши отечественные компании и институты, проектирующие по отечественным же гостам.

Постараюсь, коротенько минут на сорок дать пояснения по рассматриваемому предмету.
В практике существует три понятия "проект", точнее три варианта интерпретации термина, которые обозначают совершенно (практически) разное по смыслу:
 а) проект - как объект технологии управления проектами (подробно определение смотри в PMBOK или НТК (буквы русские). тут все достаточно понятно, пояснять здесь не имеет смысла.
 б) проект - как сам проектируемый объект: здание, конструкция, изделие и тп., в контексте "вариант/версия". Правильное название как раз такое - "проектируемый объект" или "проектируемое изделие".
 в) проект - как набор проектной документации, грубо говоря, чертежей (различных марок), схем, спецификаций, пояснительных записок и тп., которая разрабатывается в ответ на ТЗ. Правильное название - "комплект документации", но его обычно никто не использует.

Из триединости понятия возникает много путаницы, поэтому смысловая нагрузка должна быть четко разнесена. Но Вы, очевидно, спросите, а где же тут технология проектирования? и будете правы! здесь технологии проектирования нет.
Она будет посередине между вершинами тетраэдра, три из которых перечислены выше, а четвертой являются ресурсы (по сути исполнители). Технология проектирования (в отечественной интерпретации) определяет последовательность разработки проектной документации на проектируемый объект. Причем содержание выполняемых операций существенно зависит от сути (содержания) объекта. По своему опыту могу утверждать, что технология проектирования зданий и автомобилей - содержательно разные.
Управление проектами здесь пришивается довольно просто - как планирование/балансировка ресурсов для выполнения операций в заданной технологии проектирования, ну и плюс контроль выполнения, управление рисками и прочее.
Отсюда я делаю вывод о первичности технологии проектирования перед управлением проектами. Хотя с этим можно и спорить.

Мне нравится проводить аналогию проектирования к.-либо изделия с разработкой софта. тогда для технологии проектирования аналогией будет нечто вроде RUP, ресурсы и управление проектом будут иметь тот же смысл, проектная документация - соответственно, документация на софт, а модель изделия соответствует разработанному софту.
с точки зрения инструментов тоже можно провести аналогию CAD - редактор кода/RAD/компилятор и остальная шняга.
Такая схема вполне конкретно определяет место каждого компонента технологии разработки проектирования.

Но где же тут PDM/PLM? Все очень просто PDM = Source Safe.

80

Управление Проектом / Re: Декомпозиция задач в MsProject

« : 04 Декабря 2011, 00:53:42 »

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

81

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 01 Августа 2011, 23:58:36 »

каша...

82

Идеи и мозговой штурм / Re: Что влияет на качество документов Аналитика?

« : 30 Июля 2011, 23:45:05 »

"аббревиатура" еще ладно, все-таки слово туземное в своей основе. а вот слово "середина" с тремя ошибками кто-то сумеет написать? :о)))

83

Идеи и мозговой штурм / Re: Повышение производительности аналитика

« : 25 Июля 2011, 19:03:29 »

Видно баг какой-то

Неее, верстка статьи не совпадает с выделенным для нее местом, например, из-за длинных адресов ссылок (особенно та, которая про TOGAF). рекомендую правильно (с точки зрения верстки) переписать эти ссылки.

84

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 21 Июля 2011, 12:11:46 »

Все! Концепция продана... Найден какой-то 1с программист...

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

85

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 17:56:46 »

Дался тебе этот бизнес-ланч

а что? простой и понятный (теперь) термин :о)))

предлагаю все-таки двигаться в сторону традиционного управленческого цикла, а не продавать сотрудникам то, что повар-творец натворит :о)))

т.е. планируем и организуем деятельность - реализуем/контролируем - учитываем - строим отчеты и анализируем достигнутые результаты

86

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 20 Июля 2011, 17:36:31 »

Заблуждаетесь в данном случае вы.

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

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

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

87

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 17:15:46 »

Может все-таки определим критерии оптимальности?
Типа таких:
 - разумная минимизация затрат на обслуживание (считаем, что затраты на приготовление блюд постоянны)
 - минимизация затрат на контроль (при этом не исключение затрат и, собственно, контроля)
 - минимизация затрат на учет (наверное еще достоверность учета)
 - минимизация времени (затрат?) на формирование отчетности (разумеется, возможность формирования отчетности в различных разрезах)

Тут IMHO недостаточно рассматривать по отдельности процедуру заказа/выбора блюда, расчета и т.п. Тут нужно строить технологию обслуживания в целом, начиная с того, что реализуется (под видом обеда :о))) сотрудникам. Я бы посоветовал выписать в столбик (например) выполняемые операции и исключить те, которые "не приносят ценности", чтобы получить только то, без чего процесс обслуживания в принципе работать не может.

если говорить на уровне автоматов и предельной фантазии (вспоминая не то носова, не то шекли):
 - сотрудник подходит к стойке,
 - сует куда-нить свою карточку (скажем так - в считыватель)
 - открывается дверца
 - и оттуда выезжает на подносике полностью укомплектованный бизнес ланч (вариант: сотрудник самостоятельно берет subj из открывшейся ниши)
всё!

88

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:57:36 »

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

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

89

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:45:34 »

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

зачем такие сложности? "Когда у общества нет цветовой дифференциации штанов, то нет цели!" (с)
в меге, например, есть типа иппонский суши-бар (название не помню): там блюда одной стоимости ездят по транспортеру в тарелочках одного цвета. пациент клиент сам берет то, что ему нравится из представленного ассортимента. когда официант/кассир фиксирует оплату, он считает общую стоимость в этих же единицах: три синих по писят, два желтых по семьдесят, один фиолетовый по сто и т.п.

90

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:39:01 »

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

наиболее оптимальных вариантов не бывает! бывают оптимальные (по заданным критериям) и неоптимальные (по ним же) :о)))

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

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

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

а в иваново есть макдональдс? там все это уже реализовано - достаточно внимательно посмотреть.

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

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