Страница 6 из 13 ПерваяПервая ... 2345678910 ... ПоследняяПоследняя
Показано с 151 по 180 из 373
  1. #151
    Член сообщества
    Регистрация
    28.11.2005
    Сообщений
    1,326

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    Что нужно, чтобы окупился "Олимпийский", у меня фантазии не хватает. Это как купить могучий дата центр и сэкономить на электроэнергии и услугах связи
    я не в курсе_ что имеется ввиду?

  2. #152
    Член сообщества
    Регистрация
    28.11.2005
    Сообщений
    1,326

    По умолчанию

    Цитата Сообщение от Елена И. Яковлева
    В начале XX в. А.Л.Чижевский установил корреляцию солнечной активности и массовых социальных явлений
    http://russcience.euro.ru/papers/tom02i.htm
    имхо корреляцию любого природного явления с любой социальной активностью можно найти всегда-
    тут главное исторические факты правильно подбирать-
    _______-
    например - берем на такое-то число такое-то природное явление и ищем в мире - была ли социальная активность-

    Я думаю_ что это по аналогии с особенностью нашей памяти- Например_ елси событие негативное произошло после черной кошки - то оно запоминается и заносится "в статистику"_ а если само по себе - то произошло и прозошло_ никакого влияния на статистику-
    Последний раз редактировалось Елена И.; 25.05.2011 в 20:33.

  3. #153
    Член сообщества
    Регистрация
    28.11.2005
    Сообщений
    1,326

    По умолчанию

    Уважаемый друг_
    могли бы Вы как автор ветки подвести итог беседы?

    к какому выводу пришли для ответа на свой первоначальный вопрос? What s the difference between CM & PM?

    Цитата Сообщение от Александр Болдин- 30
    Change Management - это один из процессов в рамках управления проектом и вы как ИТ-шник это должны знать. То о чем вы говорите можно назвать Strategic Change Management - управление стратегическими изменениями. Это направление сейчас весьма популярно и я даже знаю людей, которые из консультантов по бизнес-процессам переквалифицировались в директоров по стратегическим изменениям.
    Цитата Сообщение от Александр Болдин - 51

    В этой ветке, обсуждая Change Management, путают два понятия с одним названием:
    1. Change Management как парадигма. Про это много, красиво и непонятно писал тот же Адизес. Потомкам остается только соревноваться в цитировании и трактовании "адисизмов" ... конечно если своего ума нет. :-Р
    2. Change Management как процесс. Здесь все четко расписано в книгах по управлению изменениями в проектах разработки ПО ... и несколько менее четко в РМВОК.
    И основные этапы процесса давно описаны:
    - Запрос на изменение (инициирование, учет, согласование)
    - Проектирование изменения
    - Верификация изменения
    - Трассировка влияния изменения на смежные блоки
    - Реализация изменения

    К числу универсальных инструментов проектирования систем с поддержкой СМ относится например Enterprise Architect: (pri chem tut instrumenti proektirovaniya pravda ne sovsem yasno - kak eto pomogaet otvetit na vopros v chem raznitsa mezhdu CM & PM)))

  4. #154
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Елена И.
    What s the difference between CM & PM?
    Помните, глупость заразна. Пытаясь ответить на глупые вопросы вы незаметно для себя становитесь глупее ... и чем дальше, тем больше.
    Поэтому все мои посты в этой ветке - это не ответы, а оценочные суждения.

  5. #155
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Выборки у нас с тобой разные...
    Это было бы здорово, но это не так - выборка одна.
    Так называемые "рыночная экономика", "эффективные холдинги" и т.п. - существуют только в книжках про бизнес ... которые пишут уставшие от борьбы с дремучим невежеством консультанты.
    Все холдинги создаются для концентрации власти. Соответственно, на позиции руководителей внизу назначаются удобные посредственности. Эти организмы обладают уникальными свойством: гибкость по направлению вверх сочетается у них с твердостью по направлению вниз.
    Если ты обслуживание данного феномена называешь "система власти" так и скажи.
    Последний раз редактировалось А.Б.; 26.05.2011 в 08:15.

  6. #156
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию Эк, ты их всех, да под одну гребенку...

    Цитата Сообщение от Александр Болдин
    Это было бы здорово, но это не так - выборка одна.
    Так называемые "рыночная экономика", "эффективные холдинги" и т.п. - существуют только в книжках про бизнес ... которые пишут уставшие от борьбы с дремучим невежеством консультанты.
    Все холдинги создаются для концентрации власти. Соответственно, на позиции руководителей внизу назначаются удобные посредственности. Эти организмы обладают уникальными свойством: гибкость по направлению вверх сочетается у них с твердостью по направлению вниз.
    Если ты обслуживание данного феномена называешь "система власти" так и скажи.
    Значит моя выборка пошире.
    Это для тебя они все одинаковые, а мне приходится работать с очень разными организациями, у топов которых потребность во власти совершенно разная. Например недавно был пример с одной очень крупной компанией, не заметил я у них потребности в "системе власти", их реально интересовало управление (кроме 2-3 чел из 15-20).

  7. #157
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Это для тебя они все одинаковые, а мне приходится работать с очень разными организациями, у топов которых потребность во власти совершенно разная.
    1) Они не одинаковые: люди все разные, но условия часто схожие. А схожие условия формируют повышенную потребность в схожих людях ... Вот и происходит концентрация (или выражаясь языком науки - отстой).
    2) Исключения лишь подтверждают правило.

  8. #158
    Член сообщества
    Регистрация
    28.11.2005
    Сообщений
    1,326

    По умолчанию

    Так_вроде картина немного проясняется

    похоже_ что наш Change Management Commitee представлял из себя на самом деле Project management office

    PMO mas informacion
    _______________________________-
    Вот еще интересная ссылка - там внизу про сравнение проджэкт менеджера и проджэект менеджмент офис - все так и есть (точнее было в той компании)-
    http://www.zinsin.ru/insur/lav_71_9....8b9d5721869b5b

    Это как анекдот про двух кобр
    Две кобры читают справочник по змеям.
    Одна говорит:
    - Смотри-ка, тут написано, что мы ядовитые!
    Вторая, просветленно:
    - Внезапно многие события моей жизни стали мне понятны...
    Последний раз редактировалось Елена И.; 26.05.2011 в 18:38.

  9. #159

    По умолчанию

    Цитата Сообщение от Елена И.
    Так_вроде картина немного проясняется

    похоже_ что наш Change Management Commitee представлял из себя на самом деле Project management office
    Близко, практически одно и то же. Я бы сказал так. И там и там цель - повышение ROI или каких-то еще фин. попугаев по типу стоимости. Там, где матрица тяготеет к сильной, там нужен PMO, там где к слабой, там нужен Change Management Office.

  10. #160
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Александр Болдин
    1) Они не одинаковые: люди все разные, но условия часто схожие. А схожие условия формируют повышенную потребность в схожих людях ... Вот и происходит концентрация (или выражаясь языком науки - отстой).
    2) Исключения лишь подтверждают правило.
    Оговорка правильная, "Часто" - но далеко не всегда. Условия задаются той самой головой у рыбы, которая.... не всегда хочет гнить.
    С уважением Виталий.

  11. #161
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию Mainstream - вести с полей

    Тезисы выступления А.И. Левенчука на круглом столе "Зрелость в управлении проектами - цель или средство".
    (http://www.slideshare.net/ailev/ss-8126587 )

    1. Методов проектного управления множество, и это нельзя недооценивать. Более того, этих методов уже четыре поколения :
    -- первое, где проектами называлось отнюдь не всё, и важна была роль сетевого планирования.
    -- второе, где проектами обзывается всё что угодно, и проектное управление шовинистически захватывает большие куски других дисциплин
    -- третье, где проекты, программы, и вообще менеджмент тесно склеены друг с другом (собственно, это деление на поколение как раз обсуждается в документах методологии третьего поколения P2M - http://www.pmaj.or.jp/ENG/P2M_Download.htm).
    -- четвертое, моделе-ориентированное - где модели продукта и модели проекта (project) тесно связываются друг с другом, а методология опирается больше на динамическое планирование и last planners ("полевых инженеров"), нежели на предварительное и first planners (специальных планировщиков в штаб-квартире). Грубо говоря, планирование становится еще более инженерным, а менеджмент - еще более личностно-ориентированным.

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

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

    4. Четвертое (моделеориентированное) поколение пока еще очень молодо. Но сама тема планирования работ, основанная на технологических производственных моделях и моделях продуктов уже поднимается во многих и многих организациях. Так, активно обсуждается (а кое-где уже делается) порождение графика работ из 3D-модели, где каждая деталька должна быть вовремя закуплена, вовремя выдана в монтаж, вовремя и без проблем с ресурсами смонтирована, вовремя проверена - и так для всего инженерного объекта в целом. План работ включает в себя не только плашку из диаграммы Гантта, но и мультфильм, где рабочему показывается, какую именно работу и с какими именно объектами делает этот рабочий, и за какое время ожидается, что он эту работу выполнит.

    5. Всё вышесказанное относится, увы, больше к более-менее понимаемым строительно-монтажным, машиностроительным и прочим "строительным/сборочным" по типу работам. Ежели речь идёт о творческой работе типа проектирования/конструирования, то тоже можно говорить о проектном управлении, но опять-таки, меняются его методы. Управление коллективным проектированием (collaborative design) и управление сооружением (construction management) - это совсем разные управления, и методы управления проектами (project) в их составе будут крайне разные. Кстати, проектный шовинизм приводит к тому, что управление проектированием и управление сооружением часто включают внутрь проектного управления, а не наоборот - задумайтесь, насколько это полезно для дела.
    ...

  12. #162

    По умолчанию

    В ИТ давно проектный "моделизм" присутствует, язычок UML даже для этого есть, для проектирования. Насчет мультиков - это здорово, всегда любил спрашивать "а что ты будешь делать"? Спасибо за обзор.

    Насчет шовинизма - это да. Вобрал в себя PM много, и я считаю много лишнего, правда из PMBoK ничего не вырежешь. Зато книжек развелось про "персонал проекта", как его мотивировать, как "быть лидером", и черти чего вообще много... прямо надоедает иногда.

    А еще PMBoK мне никогда не нравился именно тем, что ЖЦ продукта там не учитывался. Я сторонник инвест. проектирования, где весь ЖЦ продукта охватывается. Так что изменения меня только радуют. Ура.

  13. #163
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    690

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Тезисы выступления А.И. Левенчука...
    Нифига он не понимает ни в моделировании, не в планировании.
    Надо ж блин - construction management!!! Единственное модельное отличие от не construction management - мобильность и стационарности (т.е., поток несет не ресурсы, а процессоры).
    Пора все же читать Балакшина.

  14. #164
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Andruxa
    В ИТ давно проектный "моделизм" присутствует, язычок UML даже для этого есть, для проектирования.
    Строго говоря, UML - это промежуточный результат на пути воплощения мечты группы OMG (Буч, Йордан и др.) о Model Driven Archutecture... Т.е. об архитектуре информационной системы, полностью управляемой моделью.
    Однако, после создания UML должно было пройти еще 10 лет, прежде чем была создана платформа для интеграции - стандарт ISO 15926.
    Цитата Сообщение от Andruxa
    А еще PMBoK мне никогда не нравился именно тем, что ЖЦ продукта там не учитывался.
    Аналогично. Дело в том, что в РМВОКе жизненный цикл продукта начинается с момента завершения проекта - то есть находится вне системы. В отличие от мечтаний разработчиков РМВОК, в реальной ситуации жизненный цикл продукта находится внутри управления проектом, хотя и начинается со смещением относительно старта проекта.

  15. #165

    По умолчанию

    Вот и появляются в результате этого такие чудеса как проект поддержки предоставления услуги поддержки. А инвестиции должен отбивать покупатель. Правда все же есть умные менеджеры по продажам все же считают ROI и прочие NPV для продуктов. Но это редкость даже для крупных компаний.

  16. #166
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию Назад в будущее

    Лет всего 10 назад я гораздо лучше разбирался во всех без исключения предметах, связанных с управлением. Похоже, научный менеджмент тоже движется от "какие все дураки" к "кажется все немного сложнее", расшатывая картину мироздания в взрывая моск.
    Так, глядишь, придем к пониманию того, что главное-это двигаться в мэйнстриме, послав на фиг средне-, дальне-, а еще дальше- стратегическое планирование. Формула успеха предельно проста: хочешь быть успешным - будь как все, но лучше всех. Не думай, что можно чего-то достичь, будучи перпендикулярным мэйнстриму.
    Нет иной логики, чем логика мэйнстрима. Если после заявления Обамы цены на нефть просели, то вовсе не потому, что есть связь между тем, что он говорит и тем, что происходит с нефтью на самом деле. Связь находится совсем в другом месте: не "Обама-нефть", а "Обама-действие спекулянтов". Знать нужно не "как поведет себя нефть", а "как поведут себя спекулянты"
    Что же такое миссии, перспективное планирование? -просто мантры уставших консультантов для тех, кто еще способен слушать. Дальше происходит вот что: микроскопическая доля из тех, кто услышал, попробовал и у них получилось. Потому что майнстриму тоже нужны исключения, чтобы развиваться. Майнстрим оценил успех и пошел за ним. А у кого не получилось-те в очереди за бесплатным супом. Потому что система бездушна и реагирует только на результат.
    Прикол в том, что без дальнего планирования развитие действительно невозможно. Но чем дальше планирование - тем больше риски и тем меньше организаций, способных позволить себе такое удовольствие. Смотрите: в экономии бензина наметился мэйнстрим: гибриды и аккумуляторы. Лидеры не ищут перпендикулярных путей, а движутся там, где возможна суперсерия. Даже если и есть перпендикулярное решение (зола АЭС, слезы девственниц, раковый свист), оно будет лежать до тех пор, пока...

  17. #167
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Сахават
    Надо ж блин - construction management!!!
    В этом случае Левенчук прав: между управлением проектом проектирования электростанции и управлением проектом строительства электростанции есть принципиальная разница. Что характерно: в первом случае РМВОК работает, а во втором - нет.
    Причем, здесь Левенчук говорит о проектировании очень узко - как о collaborative design (совместное конструирование), тщательно обходя момент на котором у американцев случился когнитивный диссонанс с коллективным выносом мозга - вопрос различия между engineering и design.

  18. #168
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    690

    По умолчанию

    Цитата Сообщение от Александр Болдин
    очень узко - как о collaborative design (совместное конструирование)
    фигня тоже
    без определения интерфейсов никакая совместная работа невозможна
    интерфейс опредлеятся централизованно
    а дальше опять каждый кусок делается централизованно, (возможно) на другом уровне

  19. #169
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Сахават
    фигня тоже ...
    Все фигня, коме пчел ...

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

    Чтобы объяснить разницу между collaborative design и construction management нужно чтобы тот, кому объясняют, понимал что есть то и другое. Инача все объяснения будут лишь сотрясением воздуха.
    Но
    Я понимаю, Шустер понимает, ... но мне не надо объяснять Шустеру в чем соль - он и так знает. Такая вот фигня.

  20. #170
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию О перпендикулярном

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

    В качества документа рассматривается утвержденная копия базы данных, где записью является заявка на закупку товара или услуги; в совокупности они образуют Сводную Годовую Заявку (СГЗ). Которая всегда должна соответствовать Годовым Лимитам Финансирования (имеют сложную структуру, фактически бюджетирование). Лимиты могут меняться, а заявки-дорожать или дешеветь, терять актуальность, появляться внеплановыми, перераспределяться между закупающими подразделениями. В общем, с помощью системы изменений должен обеспечиваться баланс "лимит-заявка" и на любой момент времени должно быть четко известно, кому и что надо покупать.

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

    В общем, есть изменения и есть пересмотры. Для первых оформляются Извещения об изменениях, для вторых - документ переиздают и согласовывают заново. Первое - репликации, второе - полная замена версии, возможно даже со стиранием ссылок на реплики.
    Изменения удобны, когда пользователь знает исходный документ, а в извещении видит только, что изменилось. Пересмотры удобны пользователю, который либо видит документ впервые, либо пользуется им в онлайне: читаю-делаю-читаю-... Есть комбинации способов - например, выделение измененных фрагментов. Изменение возможно как "редактировать", либо как "добавить-и-старнировать", принципиальная разница в нумерации строк.

    Программеры говорят, а какая разница? Давайте будем любое утвержденное изменение сохранять, как пересмотр. То есть, каждый раз перезаписывать БД, как версию. Ресурсы-не вопрос, если что-будем хранить на дисках. Тогда изменение - это отчет "было-стало" при сравнении текущей версии с любой предыдущей, или предыдущих между собой. Можно обыграть номера версий: аналог утвержденной бумаги - V1, V2,.., изменение - V1.1, V1.2...

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

    Вопрос:
    1. Спасибо, что прочитали и извините. В голове сумбур, когда проговоришь задачу-помогает. Пока не помогло, вопрос так и не сформулирован
    2. Если кому есть что сказать-подойдет любой уровень абстракции, может моск куда-нибудь да и подтолкнется

  21. #171
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    690

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    2. Если кому есть что сказать-подойдет любой уровень абстракции, может моск куда-нибудь да и подтолкнется
    Лучше оставить
    Редакция (несущественные уточняющие изменения)
    Версия (глобальный пересмотр)

    (ресурсы и т.д. второстепенно)

  22. #172
    Член сообщества
    Регистрация
    14.02.2011
    Сообщений
    912

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    подойдет любой уровень абстракции, может моск куда-нибудь да и подтолкнется
    Задача неразрешима современными техническими одномерными линейными средствами. Нейроны мозга способны создавать многомерные связи. Следовательно, под Вашу техническую конструкцию нужен будет ЕЩЕ по кр. мере один живой человек, а не компьютер.

  23. #173
    Член сообщества
    Регистрация
    12.05.2006
    Сообщений
    2,180

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    Полтора часа с программерами чесали совокупную рэпу, разошлись практически ни с чем.
    Программисты разъехались, остались программеры?

    Цитата Сообщение от Михаил_Шустер
    В качества документа рассматривается утвержденная копия базы данных, где записью является заявка на закупку товара или услуги; в совокупности они образуют Сводную Годовую Заявку (СГЗ).
    Первая таблица - Таблица сводных годовых заявок. Дата СГЗ первый ключ.
    Вторая таблица - Таблица истории заявок на закупку.
    Дата заявки - второй (подчиненный ключ).
    Дальше еще нужна бюджетная классификация заявок. Тоже ключ в историю заявок.

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

    Если заявок на одну строку может быть много - то вводится поле "аннулировано", которое содержит истину при пересмотре (отзыве) конкретной заявки.

    Если поле "аннулировано" ввести нельзя - то для каждой аннулированной заявки вводится такая же с отрицательным знаком. И тогда выборка не по последнему, а по сумме.

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

  24. #174
    Член сообщества
    Регистрация
    12.05.2006
    Сообщений
    2,180

    По умолчанию

    Цитата Сообщение от Елена И. Яковлева
    Задача неразрешима современными техническими одномерными линейными средствами.
    Это с какой поры реляционная СУБД стала одномерной и линейной?
    ;) Это же не таблица в Йокселе.

  25. #175
    Член сообщества
    Регистрация
    14.02.2011
    Сообщений
    912

    По умолчанию

    Цитата Сообщение от Genn
    Это с какой поры реляционная СУБД стала одномерной и линейной?
    ;) Это же не таблица в Йокселе.
    С момента ее (реляционной модели данных) реализации на линейных одномерных ТС.

  26. #176
    Член сообщества
    Регистрация
    12.05.2006
    Сообщений
    2,180

    По умолчанию

    Цитата Сообщение от Елена И. Яковлева
    С момента ее (реляционной модели данных) реализации на линейных одномерных ТС.
    Что то там было про машину Тьюринга, или Тьюнинга.


  27. #177
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию

    Цитата Сообщение от Genn
    в таком примерно виде версионность бюджетов часто и реализуется.
    Спасибо
    Однако, задачу нужно решить средствами Парус Предприятие, активно пользуемой на живых данных сотнями юзеров. В Парусе нет управления репликациями, версионностью, отчетов типа "Было-Стало"; это (кроме репликаций) сделали сами.
    Мы не можем себе позволить писать крутой функционал, задача должна быть решена подручными средствами. Отдельное несложное приложение и импорт-экспорт. Возможно, Эксель. Разработчик проблему признает и готов решить за деньги, мы платим, а он потом тиражирует. Хрен ему, надо было раньше думать. Не понимаю, как вообще можно всерьез продавать системы без динамики.

  28. #178
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию

    Цитата Сообщение от Сахават
    Редакция (несущественные уточняющие изменения)
    Версия (глобальный пересмотр)
    Ты сводишь к интерфейсной задаче?
    Приоритеты? Основных переменных параметров всего 4: номенклатура, цена, количество, подразделение-снабженец, все равноприоритетные. Про остальные пока не задумывались: их корректируют на стадии договорной спецификации, согласовывая на бумаге. Это важный раздел, но я не о нем.

  29. #179
    Член сообщества
    Регистрация
    14.02.2011
    Сообщений
    912

    По умолчанию

    Цитата Сообщение от Genn
    Что то там было про машину Тьюринга, или Тьюнинга.

    конечно, и про архитектуру фон Неймана. А еще - всяческое непрекращающееся сопровождение и доработка приложений ...

  30. #180
    Член сообщества
    Регистрация
    12.05.2006
    Сообщений
    2,180

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    Однако, задачу нужно решить средствами Парус Предприятие, активно пользуемой на живых данных сотнями юзеров. В Парусе нет управления репликациями, версионностью, отчетов типа "Было-Стало"; это (кроме репликаций) сделали сами.
    Вот за изучение функционала Паруса я деньги возьму.

    Цитата Сообщение от Михаил_Шустер
    Отдельное несложное приложение и импорт-экспорт. Возможно, Эксель.
    В Йокселе это ложится в 2 рабочих листа.
    Но требует дисциплины оператора рабочей книги.
    В Аксесе - тоже реализуется довольно просто.

    Вам просто надо найти программиста - белая логика на первой или второй базовых функциях в модели А. (ДонКихот, Робеспьер, Максим, Жуков) Для вас - как возможного представителя Гаммы - это может быть и сложно, но ... просто найдите адекватного исполнителя.

    ... или пишите в л/с.
    Последний раз редактировалось Genn; 30.05.2011 в 22:37.

Страница 6 из 13 ПерваяПервая ... 2345678910 ... ПоследняяПоследняя

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •