Разработка КСУП - методы, критерии, результаты, внедрение
16 декабря 2008 в 03:33

Разработка КСУП - методы, критерии, результаты, внедрение

Обсуждаем подходы и методики построения и внедрения корпоративных систем УП.

941
Комментарии (48)
  • 16 декабря 2008 в 08:08 • #
    Виктор Клепа

    Поскольку я первый в этой ветке. Хотелось бы сразу заметить, что КСУП- это не программное обеспечение и разговоры типа: "Наша КСУП построена на PRimavera (MS Project, Spider Project)..." в корне ошибочна.

  • 16 декабря 2008 в 09:55 • #
    Георгий Ковалев

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

  • 17 декабря 2008 в 18:43 • #
    Виктор Клепа

    Вот чего боялся- то и произошло! Начали опять обсуждать Projectы, Спайдеры, Примаверы и т.д. А жаль! Если это поможет притормозить эту волну, то я заявляю, что Спайдер- ЛУЧШИЙ, хотя им не пользуюсь в своей профессиональной деятельности (более 7 лет) и никакого отношения к компании Спайдер Проджект не имею и программы их не продаю и т.д..
    Просто я считаю, что беда нашего менеджмента не в том, что он с ИСУП или без нее, а в том что система планирования и подготовки производства, КУЛЬТУРА производства сильно корозировала. И поверьте, никакой новоиспеченый коекакер, пардон, менеджер эту ситуацию не изменит, как в прочем и стандарты предприятия, в том числе и их совместный симбиоз. Поскольку эффективность КСУП в первую очередь зависит от ЗРЕЛОСТИ ОРГАНИЗАЦИИ и естественно людей из которых она состоит. Вот на эту тему и хотелось бы поговорить. Поэтому, я призываю: ЛЮДИ, ЧЕЛОВЕКИ, КОЛЛЕГИ !!! Давайте поговорим о достигнутых результатах, возникших проблемах, методах решения внедрения КСУП. Сразу вопрос: У кого есть утвержденная высшим руководством стратегия развития КСУП, допустим до 3-го (4-го) уровня проектной зрелости?

  • 17 декабря 2008 в 21:38 • #
    Владимир Либерзон

    Вы совершенно правы. Программное обеспечение это инструмент СУП, а не панацея. И внедряется СУП, если к такому внедрению подошли как к серьезному проекту. То есть назначили руководителя внедрения и команду, разработали Устав (ТЗ), составили и утвердили план, распределили ответственность, наладили учет и контроль, регулярно проводят совещания, осуществляют приемку результатов. Необходимо, чтобы была поставлена четкая цель руководством организации.
    В своих контрактах на внедрение мы обязываем клиента ежемесячно проводить совещание у первого лица организации для рассмотрения хода внедрения и решения возникающих проблем.
    Роль первого лица просто огромна, без поддержки сверху вероятность неудачи слишком велика.

    Наверное интересно было бы проанализировать допущенные ошибки. Потому я бы ваш вопрос дополнил еще одним - о тех ошибках, которые делались при внедрении СУП, что мешало или мешает добиться нужного результата?

  • 17 декабря 2008 в 22:57 • #
    Георгий Ковалев

    Виктор!
    О каком 3-м или 4-м уровне Вы говорите? Вы знаете компании с работающим 2-м уровнем? (оговорка: российские компании, то что пришло из-за границы брать в расчет не стоит).

  • 18 декабря 2008 в 08:16 • #
    Виктор Клепа

    Я пытаюсь это сделать в своей организации. Признаюсь идет очень тяжело, но прогресс есть движение вперед, а не переход от плохого к хорошему. В этом году (в авральном режиме) мы сформировали новый принцип планирования работ наших подрядчиков (около 2500 человек на площадке строительтсва) и контроля хода исполнения проекта. Сформировали график выполнения работ, привязали его к графику поставки оставшегося оборудования и материалов (около 8000 позиций), графику выдачи рабочей документации, работы распределили по подрядным организациям, оценили физические объемы работ и трудозатраты. Произвели анализ графика и сформировали 3 варианта развития событий (оптимистичный, пессимистичный и наиболее вероятный). Сразу скажу, что результаты очень удивили руководство (возможно даже расстроили) , потому как полученные сроки сильно зависили от наращивания численности персонала на площадке, а его взять негде. Так что потихоньку мы движемся по этой лестнице вверх.

  • 18 декабря 2008 в 09:54 • #
    Георгий Ковалев

    Дайте угадаю фразу, с которой Вас провожало руководство... "Да мы уже 10 (20,30 - нужное подчеркнуть) лет строим без вашего пиэмбУка, а вы мне тут штат в два раза хотите раздуть" ; ) И смех и грех, как говориться... Я сам внедрял КСУП в течение 3-х лет на различных предприятиях, от строителей до разработчиков софта и поэтомы Ваши трудности внедрения мне ооочень хорошо знакомы. Удачи Вам на этом не легком пути!

  • 18 декабря 2008 в 15:05 • #
    Игорь Цесельский

    А какой инструмент использовали?

  • 18 декабря 2008 в 17:43 • #
    Виктор Клепа

    Primavera

  • 9 апреля 2009 в 16:56 • #
    Эдуард Семенов

    Виктор на счет удивления руководства - очень с вами согласен около 7 лет назад начиная свою работу менеджером проектов в проекте построения слаботочной инфраструктуры для строящегося здания управления "Татэнерго", попытался применить методику проектного управления не только к строительству непосредственно слаботочки но и к строительству объекта в целом (причем без всякого вознаграждения- что называется ради "пробы пера" -(молодой был горячий :)) ), когда мои план проекта (понятно что он был составлен с очень небольшой степенью детализации и в очень общем виде) показал что проект при таких темпах работ отстанет от декларируемых сроков на два года!!!! ,я с этим пришел к директору строящегося здания (мужику было лет 50 тогда) и мы поговорили примерно в таком раскладе- "что все это интересно но у него на стене висит обищй график производства работ (который на тот момент уже отставал на 3 месяца), и все отставания они догонят, он "надавит" на генподрядчика и все встанет на свои места, в общем когда реально сройка закончилась на 2 года позже запланированной, я понял что Проектный Менеджмент -это сила :)), но так же понял что наши строители вряд ли будут его применять (и кстати на протяжении 7 лет я не слышал чтобы у нас в Казани ктото из строителей, даже те кто строит коммерческое жилье и кому вроде бы есть жесткая необходимость применять данные методы, их применял, хотя конечно не претендую что имею информацию по всему рынку)

  • 28 марта 2009 в 16:34 • #
    Александр 111

    да ....именно...хотя бы второй...
    но похоже и первым педко пахнет

  • 16 декабря 2008 в 10:01 • #
    Максим Мотин

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

  • 16 декабря 2008 в 10:57 • #
    Владимир Либерзон

    Максим,
    с "Организатором строительства Богучанской ГЭС" вы как-то связаны?

    И какими проектами вы собираетесь управлять по описанной вами схеме?

  • 17 декабря 2008 в 14:02 • #
    Максим Мотин

    Владимир, добрый день. С Организатором находимся в одном здании, наши организации связаны договорными отношениями . К управлению строительством отношения не имеем, по описанной схеме планируем управлять проектами по внедрению ИТ-систем и телеком-проектом.
    Учитывая, что ресурсов у нас не так много на проектную деятельность ( в основном, все ресурсы уходят на поддержку) я думаю, что ёё будет достаточно.
    Был у Вас на курсах по основам управления проектами в Спайдере (в г. Кодинске).
    Естественно, набор работ в ИСР у нас будет укрупненным, не более нескольких десятков.

  • 17 декабря 2008 в 14:48 • #
    Владимир Либерзон

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

  • 18 декабря 2008 в 07:50 • #
    Максим Мотин

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

  • 13 января 2009 в 09:50 • #
    Вадим Богданов

    Максим, добрый день!

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

    С уважением,
    Вадим

  • 13 января 2009 в 15:38 • #
    Максим Мотин

    Спасибо за предложение :)
    Пока работы по интеграции у нас в планах не стоят, если задумаемся над этим предметно, буду иметь ввиду.

  • 10 апреля 2009 в 14:30 • #
    Вадим Богданов

    Кстати, у нас есть типовой модуль интеграции смет с CAD, с нормативами работ и далее с Project.

  • 16 декабря 2008 в 16:18 • #
    Игорь Цесельский

    Безусловно. Важно, чтобы это понимали все.
    Поэтому и создана эта ветка, в отличие от конфы
    Программы для управления проектами
    https://professionali.ru/Topic/201943

  • 16 декабря 2008 в 11:16 • #
    Владимир Либерзон

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

  • 16 декабря 2008 в 11:40 • #
    Анастасия Мещерякова

    Владимир, Браво! просто профессиональный подход.
    Если бы все постановщики задачи и менеджеры проектов думали и решали свои задачи именно так, то вообще вопроса подходов и выборов ПО по УП у людей не было.
    Единственное, участвуя в комплексных проектах внедрения ERP, напр. в SAP модуль PS - внедрять на стадии развития системы, а не сразу.
    Сначала наведите порядок в умах всех работающих и ИТ специалистов, публикуйте свои разработки и историю успеха внедрения ERP, а потом двигайтесь дальше.
    ИСО 9001-> BSC-> ERP - точно работает на практике

  • 16 декабря 2008 в 12:21 • #
    Валерий Грачев

    Абсолютно правильно.
    Очень рад, что появился на форуме такой специлист ( не побоюсь сказать, один из гуру проектного управления) как уважаемый господин Либерзон.
    Все взаимосвязано. И подход к разработке и внедрению КСУП ( а под этим я понимаю Корпоративную систему управления проектами) должен быть именно такой.
    А служба ИТ это только инструмент.

  • 16 декабря 2008 в 16:22 • #
    Игорь Цесельский

    В части роли ДИТ - согласен однозначно. Это - эксплуатация.
    С другой стороны, выбор ПО УП тесно связан с ПО управленческого учета, которое как правило появляется раньше других составляющих ERP.

  • 16 декабря 2008 в 16:26 • #
    Владимир Либерзон

    И если управление проектами изначально не предусмотрено в УУ, то это создает серьезнейшие проблемы в организации. Далеко не всегда управленческий учет появляется первым. Из нашей практики это, слава богу, не следует.

  • 16 декабря 2008 в 16:44 • #
    Игорь Цесельский

    Владимир, без СУП живут и здравствуют многия и многия, а без СУУ - никто, согласитесь. Другое дело, что с грамотно внедренной СУП работа фирмы эффекивней по результатам. Без СУУ просто работа никакой фирмы невозможна по определению.
    В отношении стартапов - есть возможность изначально заложить грамотную структуру.

  • 16 декабря 2008 в 16:53 • #
    Владимир Либерзон

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

  • 16 декабря 2008 в 16:59 • #
    Игорь Цесельский

    А про ERP речи не было, ибо помимо УУ и УП ERP интергрирует (в идеале) все основные БП предприятия.

  • 16 декабря 2008 в 17:10 • #
    Владимир Либерзон

    Цитирую: С другой стороны, выбор ПО УП тесно связан с ПО управленческого учета, которое как правило появляется раньше других составляющих ERP.

    Возможно я вас не так понял, но вытекало, что вы пишете об автоматизированном управленческом учете.

  • 16 декабря 2008 в 17:58 • #
    Игорь Цесельский

    Правильно - УУ как одна из составляющих ERP.
    Задача ERP - системная интеграция подсистем менеджмента предприятия. и не более того. А уж автоматизация - это сверхзадача. Пока ни у кого не видел.
    Дискуссия здесь
    https://professionali.ru/Topic/111098

    Результатты по УУ ИМХО предсказуемы (я за опрос - да), по меньшей мере 1С есть у всех (или более мощный пакет).
    Предлагаю только провести опрос в ключе - у кого НЕТ системы УУ.
    Потом. слово автоматизированный лично у меня вызывает, гм, сомнения.
    В свете вышесказанного и горячей дискуссии, перешедшей в "а ты кто такой" в стиле Балаганова с Паниковским.

  • 16 декабря 2008 в 19:16 • #
    Владимир Либерзон

    По моему нормальная дискуссия. Не вижу ничего обидного ни для кого.

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

    Напомню, что вы писали, что обычно сначала внедряется ПО управленческого учета, и только потом люди задумываются о ПО управления проектами. В моей практике то и другое внедряется параллельно.

  • 16 декабря 2008 в 20:30 • #
    Игорь Цесельский

    Не здесь. а по ссылке выше постом.
    В 1С можно очень много чего, даже УП. А уж УУ в 1С - это вообще норма.
    Да, в Радуге велся УУ корпорации с чилленностью более 1000 чел и более 30 филиаловпо Европе. Разработка велась своими силами. Впрочем, это другая история для другой темы.
    Я утверждаю, что УУ - это первейшая необходимость для любой компании, а до внедрения КСУП фирме надо дорасти. А вот с этим в РФ дело обстоит плохо, степени зрелости 4 и 5 не достигла ни одна из компанмй.

  • 17 декабря 2008 в 01:16 • #
    Владимир Либерзон

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

  • 17 декабря 2008 в 02:58 • #
    Игорь Цесельский

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

  • 17 декабря 2008 в 11:28 • #
    Александр 111

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

  • 17 декабря 2008 в 11:46 • #
    Владимир Либерзон

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

  • 17 декабря 2008 в 11:53 • #
    Александр 111

    я и говорю что нужен лидер чтоб он отвечал. а вы про что? у вас в голове мутно по кажется.

  • 17 декабря 2008 в 12:24 • #
    Владимир Либерзон

    Перечитайте мой ответ еще раз, может быть поймете я про что.

  • 17 декабря 2008 в 18:06 • #
    Виктор Клепа

    Браво! Владимир! Давно слежу за работой Вашей организации- действительно профессиональный подход. Дай Вам бог попутного ветра.

  • 17 декабря 2008 в 22:50 • #
    Владимир Пастушенко

    Блог описывающий полный цикл от выбора жо внедрения и эксплуатации системы управления проектами и процессами для географически распределённых рабочих групп вот тут

    http://vladpast.livejournal.com/tag/%D0%92%D1%8B%D0%B1%D0%BE%D1%80+%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B+%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F

    P.S.
    Но тут не упирается всё в софт. Очень важны методологии и подходы. И просто разумное управление

  • 18 декабря 2008 в 04:42 • #
    Игорь Цесельский

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

  • 2 апреля 2009 в 23:01 • #
    Мария Малинина

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

  • 2 апреля 2009 в 15:57 • #
    Мария Малинина

    Хотелось бы уточнить, а что Вы, Игорь, подразумевали, под ВЫБОРОМ КСУП?
    Получается, что для КСУП существуют коробочные решения (ну с плюс-минус какими-то настройками), из которых можно выбирать?
    Я понимаю, если бы речь шла о ПО, тогда есть из чего выбирать, но КСУП?
    Или Вы имели в виду, какие элементы с какой степенью детализации прорабатывать при разработке и внедрении КСУП?

    КСУП разрабатывается и внедряется для каждого заказчика индивидуально.
    Что касается метода - равномерная разработка трех составляющих: НРБ, персонал и ИСУП. Под равномерной подразумевается планомерный ход от укрупненного видения взаимосвязи этих элементов (на еще более раннем этапе - определение того, чего клиент ждет от КСУП, какие задачи хочет с ее помощью решать), определение их параметров и характеристик, отвечающих поставленным задачам. А далее - методичная прорабокта каждого из этих трех элементов.

    Критерии - задачи, которые призвана решить КСУП (это подразумевает и место проектов во всей деятельности компании, и типы проектов, и проч.).

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

    ... И тогда результаты будут соответствовать ожиданиям.

  • 2 апреля 2009 в 15:58 • #
    Мария Малинина

    Хотелось бы уточнить, а что Вы, Игорь, подразумевали, под ВЫБОРОМ КСУП?
    Получается, что для КСУП существуют коробочные решения (ну с плюс-минус какими-то настройками), из которых можно выбирать?
    Я понимаю, если бы речь шла о ПО, тогда есть из чего выбирать, но КСУП?
    Или Вы имели в виду, какие элементы с какой степенью детализации прорабатывать при разработке и внедрении КСУП?

    КСУП разрабатывается и внедряется для каждого заказчика индивидуально.
    Что касается метода - равномерная разработка трех составляющих: НРБ, персонал и ИСУП. Под равномерной подразумевается планомерный ход от укрупненного видения взаимосвязи этих элементов (на еще более раннем этапе - определение того, чего клиент ждет от КСУП, какие задачи хочет с ее помощью решать), определение их параметров и характеристик, отвечающих поставленным задачам. А далее - методичная прорабокта каждого из этих трех элементов.

    Критерии - задачи, которые призвана решить КСУП (это подразумевает и место проектов во всей деятельности компании, и типы проектов, и проч.).

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

    ... И тогда результаты будут соответствовать ожиданиям.

  • 4 апреля 2009 в 04:58 • #
    Игорь Цесельский

    Сложилось впечатление, что вы не читали мой пост.
    В свою очередь, хотелось бы уточнить, а что Вы, Мария, подразумевали, под ВЫБОРОМ КСУП?
    У меня - "выбор инструментального средства для создания КСУП".
    Разницу замечаете?
    У вас - "Получается, что для КСУП существуют коробочные решения (ну с плюс-минус какими-то настройками), из которых можно выбирать?"
    У меня "Следовательно, внедрение КСУП в каждом конкретном случае уникально."
    Не получается, Мария. Шаблоны - есть, а готовых универсальных рецептов практически нет.

  • 7 апреля 2009 в 10:17 • #
    Мария Малинина

    В том то и дело, что в теме написано - "Выбор КСУП: методы, критерии,... ", а дальше текст: "Обсуждаем подходы и методики выбора и внедрения корпоративных систем УП", поэтому я и удивилась. А вот формулировка "Выбор иструментального средства для создания КСУП", разумеется, не вызывает вопросов.
    И именно поэтому я ничего не подразумевала под "выбором КСУП", потому что для меня это непонятне словосочетание. Фраза "Получается, ..." как раз была риторическим вопросом, который подразумевал ответ "Нет, не получается".
    А насчет Вашего "Следовательно, внедрение КСУП в каждом конкретном случае уникально." - я уже извинилась, поскольку в свзяи с некоторыми проблемами интернета Ваш пост я не увидела (см. ответ на Ваше сообщение от 18 декабря).

    Еще раз прошу прощения за внесенную сумятицу.

    Все остальное, кроме моего вступления про то, что есть "выбор КСУП", я готова повторить.

  • 7 апреля 2009 в 15:08 • #
    Игорь Цесельский

    Я понял. Согласен, но...
    Мария, в заголовке темы затруднительно уложить все ньюансы.
    В содержательной части тема раскрыта.
    Разумеется, правильнее "Выбор (пути. методы, способы и тп) создания, разработки и тп....
    Давайте попробуем тему в таком варианте.
    Разработка КСУП - методы, критерии, результаты, внедрение

  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?