PLM попроще

[walery]

В практике постоянно возникает необходимость в информации по текущим заказам, разработкам и т.п. Но эта информация как правило оказывается разбросанной по разным местам, компьютерам, базам данных и составить представление о текущем положении дел на текущий момент занимает длительное время и в основном на основе воспоминаний и отрывочной информации. Вот бы найти основные спецификации по построению подобной системы, но не заумными средствами за жуткие деньги, а для малого предприятия. Может быть начать с минимальных возможностей, но со способностью к наращиванию.
PLM(product lifecycle management).
Для начала можно рассмотреть варианты использования жизненного цикла продукта в целом:

• изучение рынка и формирование требований к продукту
• разработка, дизайн, функции, рабочая документация
• продажа, сопровождение, обслуживание, поставки КИ, изготовление(выпуск), поставки готовых изделий
• анализ продаж, реализация незавершённого производства, прекращение выпуска продукта

[wivern]

Хм, впечатляет.
Какие потребности малого предприятия (SOHO) можно было бы выделить как основные?
Потому как вышеперечисленное это огромнейшие направления в которых существуют десятки решений самого разного масштаба.

[walery]

Наличие большого количества решений, часто означает, что его вовсе нет, т.к. ознакомиться с большим кол-вом решений нет ни желания, ни возможности.
Потребности такие:
- минимальная стоимость;
- простота использования;
- надёжность и защищённость работы;
- мобильность, как составная часть сервиса;
- управление доступом рабочего коллектива, администрирование.
- экономический анализ состояния, расширение;
Построение системы на основе WEB-сервисов позволит расширять систему. В частности, у меня потерялось проектная документация из-за сбоя компьютера; т.к. не было хранилища текущей версии проекта.
Сметные позиции по проекту постоянно меняются и, кроме того, было бы полезно заказчику или инвестору иметь доступ к этой информации, т.к. всегда есть элемент подозрения нецелевого использования средств или представление о стоимости комплектующим или выполняемых работ и сроков их выполнения. Т.к. стоимость проекта складывается из множества фрагментов и рассказать почему такая цена не всегда получается убедительно. По этому появление нового продукта или услуги может вовсе завязнуть в "долгостой".
Ещё один аспект, один и тот же документ используется в различных разделах проекта. Использование файловой системы на локальной машине не в полной мере решает этот вопрос, т.к. отсутствует описание контекста, в котором рассматривается документ; этот контекст приходится держать в уме, что утомительно, не удобно и основано на человеческом факторе, т.е. надо помнить контекст для этого документа. Или наоборот, с конкретным документом должен быть связан определённый контекст, один или несколько.
Например, техническое описание на микросхему схемотехник рассматривает с точки зрения функции, технолог с точки зрения установки/монтажа, снабженец с точки зрения нормоупаковки и т.д. На разных этапах разработки и с разных аспектов данная микросхема выглядит по разному. Таким образом, схемотехник предлагает использовать микросхему; технолог изучает возможности монтажа с точки зрения имеющегося оборудования и требований по монтажу для данной микросхемы, возможно вносит предложения по модернизации оборудования; снабжение изучает вопросы нормоупаковки, цены и сроков поставки. Сводя всё вместе приходим к обоснованному решению о применении данной микросхемы и что немаловажно, эта информация доступна каждому участнику и изменения поступают незамедлительно. Но вот чтобы всё свести вместе нужна некоторая информационная система, которая эту информацию собирает, хранит и предоставляет авторизованным пользователям в нужный момент, в любое время суток, в праздники и будни, на работе и в командировке.
Неоднократные попытки использовать разные способы в конечном счёте распадались, т.к. локальные машины меняются, проходит рассмотрение разных проектов и способов решения и некоторые вещи забываются и посмотреть их оказывается негде, т.к. надо помнить в каком файле и в какой папке это лежит. А память ограничена и использовать её для описания файлов в разных компьютерах не рационально. А с использование сетевых компьютеров, типа iPad, это вовсе невозможно, т.к. для хранения гигабайт информации за прошлую пятилетку нет вовсе ресурсов у этих устройств. А творческий человек работает в любых условиях и ему офис для продуктивной работы не обязателен: "концептуальную модель для проекта или алгоритм можно продумывать и лёжа в ванне, или на лесной полянке и т.д.".

[wivern]

ознакомиться с большим кол-вом решений нет ни желания, ни возможности.

Что поделаешь? Рынок.

Потребности такие:
- минимальная стоимость;
- простота использования;
- надёжность и защищённость работы;
- мобильность, как составная часть сервиса;
- управление доступом рабочего коллектива, администрирование.

Я бы сказал, что это ограничения, пожелания, требования наконец, но никак не потребности.

- экономический анализ состояния;

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

Построение системы на основе WEB-сервисов позволит расширять систему.

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

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

Это печально, но как я понимаю к хранилищу PLM никакого отношения не имеет.

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

Гм, ну на примере проектов по разработке ПО, инвестор не будет смотреть исходный код, его интересует project management.

Т.к. стоимость проекта складывается из множества фрагментов и рассказать почему такая цена не всегда получается убедительно.

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

По этому появление нового продукта или услуги может вовсе завязнуть в "долгостой".

Таки да, но как тут поможет ПО?

Например, техническое описание на микросхему схемотехник рассматривает с точки зрения функции, технолог с точки зрения установки/монтажа, снабженец с точки зрения нормоупаковки и т.д. На разных этапах разработки и с разных аспектов данная микросхема выглядит по разному. Таким образом, схемотехник предлагает использовать микросхему; технолог изучает возможности монтажа с точки зрения имеющегося оборудования и требований по монтажу для данной микросхемы, возможно вносит предложения по модернизации оборудования; снабжение изучает вопросы нормоупаковки, цены и сроков поставки. Сводя всё вместе приходим к обоснованному решению о применении данной микросхемы и что немаловажно, эта информация доступна каждому участнику и изменения поступают незамедлительно. Но вот чтобы всё свести вместе нужна некоторая информационная система, которая эту информацию собирает, хранит и предоставляет авторизованным пользователям в нужный момент.

CAD/CAM/CAE + документооборот только проблема в том, что это решение уровня НИИ со штатом так примерно в 1000 человек.

Неоднократные попытки использовать разные способы в конечном счёте распадались, т.к. локальные машины меняются, проходит рассмотрение разных проектов и способов решения и некоторые вещи забываются и посмотреть их оказывается негде, т.к. надо помнить в каком файле и в какой папке это лежит.

Мне кажется, это скорее от отсутствия системы ведения проекта. Тут никакое ПО не поможет. Под системой я имею в виду некоторую методику по управлению проектами для начала на бумаге, затем можно автоматизировать. А внедрение автоматизации в бардак поможет только создать автоматизированный бардак, а на деле ничего не изменится. Хотя нет, пардон, изменится, в худшую сторону, т.к. добавится ограниченность и неидеальность ПО, а еще надо будет потратить какое-то время на его изучение.  

В общем тема интересная, хотя и мутная. И пока что я не увидел реальных потребностей.

[walery]

Я уж боюсь писать; прямо в желании что-то покритиковать критикуется всё под ряд и без разбора. Для начала эта фраза: "нужна нехилая такая инфраструктура," Часть проекта beetle построена на этих самых "нехилых структурах" и если б знал что это так круто, то резко повысил бы своё самомнение. Но на самом деле, если знаешь предмет он не сложен, а сложен только при наличии незнания. Так долгое время считалось, что гром приносит вред, пока не открыли электричество.
Представляет интерес обсуждение поиска проблемы и способов решения, а нигилизм и  повсеместное усложнение с целью загнать всё в тупик, говорит о нежелании что либо делать. Так ведь никто и не принуждает.
Как показывает история, можно ничего вовсе не делать, всё будет сделано другими. Это общая политика, как я наблюдаю, даже высоких политик: типа путь "там" всё разработают, а мы купим. Это может применимо только для ГазПрома. Но страна состоит не только из членов этой партии. Политика такая ведёт к упадку во всех областях, в том числе и в развитии личности. "Зачем учить Географию, когда есть извощики?". И т.д. ...

[walery]

Вот к примеру система должна иметь SMS сервис, подобие этого

[wivern]

Я уж боюсь писать; прямо в желании что-то покритиковать критикуется всё под ряд и без разбора.

Я искренне пытаюсь понять суть проблемы без всякой критики ибо критиковать-то собственно нечего.

Для начала эта фраза: "нужна нехилая такая инфраструктура," Часть проекта beetle построена на этих самых "нехилых структурах"

Тот факт, что в beetle используются веб-службы не дает основания полагать, что он может сколь угодно масштабируемым.

Но на самом деле, если знаешь предмет он не сложен, а сложен только при наличии незнания.

Обратное также справедливо, от незнания предмет может казаться очень простым.

Представляет интерес обсуждение поиска проблемы и способов решения, а нигилизм и  повсеместное усложнение с целью загнать всё в тупик, говорит о нежелании что либо делать.

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

Вот к примеру система должна иметь SMS сервис

Мне это нравится, а 3D интерфейс она не должна иметь заодно?
Я в том смысле, что я не против SMS-сервиса, но едва ли это основная функция системы.
Так что давай определим основную потребность, сделаем для себя, определим насколько эта вещь востребована на рынке и начнем уже наконец зарабатывать на ней.

[walery]

Я не знаю где ключ от квартиры где деньги лежат.
Я пытаюсь рассказать свои проблемы, а не панацею от всего. Если мои проблемы не понятны и не интересны, так незачем и писать какие-то комментарии. Думается, что похожие задачи возникают у многих разработчиков/изготовителей продукции, если только не использовать социалистический принцип(он де армейский): то что может сделать один, сделаем вместе.
Этот принцип гарантирует право каждого на труд, ну то есть корку хлеба, этот же принцип гарантирует всем равные права, то есть уравниловку. НУ и массу прочих так называемых социальных защит. Эта сказка называется коммунизм. И партия наш рулевой. Это я всё к тому, что если решать задачу всеобщей занятости, то любая автоматизация вредна, и фон Нейман наш первый "враг".
Сухой остаток. Давай сначала решим свои проблемы, а потом решение предложим другим, если решение будет стоящим. Кроме того продвижение и постановка решения по автоматизации управления, сам знаешь, дело не простое. Достичь уровня Rose будет очень не просто, да и у них не всё гладко.
Поэтому предлагаю определить несущую конструкцию, которая позволяет себя канфигурировать для разных применений. В основе этой конструкции WEB-сервис, как наиболее гибкий и подключаемый конструктив со стандартным и простым интерфейсом. Грамотный набор этих WS и есть ключь для гибкого построения систем разного масштаба.

[wivern]

Я пытаюсь рассказать свои проблемы, а не панацею от всего. Если мои проблемы не понятны и не интересны, так незачем и писать какие-то комментарии.

Интересны, но пока непонятны. Потому и вопросы.

Думается, что похожие задачи возникают у многих разработчиков/изготовителей продукции, если только

Скорее всего, почти наверняка, но не у всех производителей, а наверное у производителей вполне конкретной продукции.
Решить все мировые проблемы одним программным продуктом вряд ли получится. Прочую лирику опустим.

Сухой остаток. Давай сначала решим свои проблемы, а потом решение предложим другим,

Я собственно именно этим и предлагал заняться.

если решение будет стоящим.

Будет, если правильно ставить цель.

Кроме того продвижение и постановка решения по автоматизации управления, сам знаешь, дело не простое.

Да уж.

Достичь уровня Rose будет очень не просто, да и у них не всё гладко.

Да и ни к чему, у них свои игры, у нас свои.

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

Разве ж я против, я только за.

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

А вот сие есть очень спорно. Я уж не говорю о том, что сферический веб-сервис в вакууме - это фикция.
Давай тогда подробнее разберемся что такое веб-служба?
Если отбросить лишнее, то веб-служба представляет собой некое соглашение о способе передачи данных.
При этом не оговаривается ни архитектура, ни принципы построения системы. !!!
Стоит также иметь в виду, что если имеется исходный код системы, то в случае необходимости добавить к нему интерфейс в виде веб-службы не представляет сложности. Более того, существует, например, такой проект как Crispy, который позволяет "выбирать" протокол не меняя кода приложения из довольно приличного набора протоколов, в т.ч. и SOAP. Но это так, к слову.
Спектр применения веб-служб довольно широк, но не следует забывать что это всего лишь средство и оно не является серебряной плуей и диапазон его применения хоть и широк, но все же ограничен.
Применение того или иного средства не может быть целью проекта, разве что это учебный проект, но это ведь не наш случай.
Так что есть предложение: сосредоточиться именно на цели, т.е. на том, какие проблемы необходимо решить, а средства для их решения будем подбирать сообразно этим целям и доступным ресурсам (денежным, человеческим и т.д.).

[walery]

Мы тут Жизненный Цикл Продукта начинали обсуждать.
Если о текущих проблемах, то у меня на очереди Синтаксический разбор SMS сообщения. Это составная часть PLM. В данный момент я работаю на другом компьютере по сравнению с предыдущим этапом. Надо не забыть DVD с архивом документации(технические описания), палочка памяти с текущими материалами. Всё это надо перенести на другую машину. На ней папки другие, диски другие, если что то понадобится, надо переползать на первую машину; там найти, скопировать и началось. Потери времени значительные. Вот и проблема. По сути на пустом месте. Как предлагается решать?

[wivern]

Мы тут Жизненный Цикл Продукта начинали обсуждать.
Если о текущих проблемах, то у меня на очереди Синтаксический разбор SMS сообщения. Это составная часть PLM. В данный момент я работаю на другом компьютере по сравнению с предыдущим этапом. Надо не забыть DVD с архивом документации(технические описания), палочка памяти с текущими материалами. Всё это надо перенести на другую машину. На ней папки другие, диски другие, если что то понадобится, надо переползать на первую машину; там найти, скопировать и началось. Потери времени значительные. Вот и проблема. По сути на пустом месте. Как предлагается решать?

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

Что такое синтаксический разбор SMS сообщения и какое отношение он имеет к PLM, мне, например, непонятно.

Что касается PLM, вообще, то в моем первом сообщении есть ссылка на статью в вики, где очень доходчиво написано что входит в понятие PLM, в частности это: CAD/CAM/CAE, SCP, CRM, ERP, MRP и/или MRP-II и т.п.
Мне более всего знакомы системы типа CRM (Customer Relationship Management), например, SugarCRM. И просто гляда на то, что там уже сделано, понятно что команда из 2х человек не в состоянии сотворить подобное в обозримый срок.

[walery]

Синтаксический разбор - это частный случай для примера в данном случае. Очень нужная вешь - система PLM. Но всё никак не попадается подходящая, рабочая система. Пока используется форум. Предполагаю, что это может стать прототипом для развития направления. Пока добавились проблема с ДНС, которая мешает развитию процесса формирования требований, спецификаций.

[wivern]

Не совсем PLM (хотя по описанию близко) и простота весьма относительная, но все же вдруг поможет PSS Lite